**** BEGIN LOGGING AT Sun Nov 10 02:59:58 2013 Nov 10 22:28:07 so i need to override Yocto and make it point to a custom eglibc Nov 10 22:28:20 how do i make it point to a local directory to source it? Nov 10 22:28:37 if i use file:// it looks in some prespecified paths rather than a whole path i give it :/ Nov 10 22:29:51 Messoroz: I'd suggest using the externalsrc class for that Nov 10 22:30:28 Messoroz: http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#building-software-from-an-external-source Nov 10 22:31:14 hmm Nov 10 22:31:24 can i make it use an archive as the source? Nov 10 22:31:28 or must it be an expanded tree? Nov 10 22:32:30 Messoroz: oh, well if it's that that you're after, just set SRC_URI Nov 10 22:32:42 yea Nov 10 22:32:46 well i just have a modified eglibc Nov 10 22:32:47 you need file:///path/to/src/archive.tar.gz Nov 10 22:32:59 already packaged to cope with it being broken for a chip Nov 10 22:33:08 do i need to update the checksums? Nov 10 22:33:18 you would yes Nov 10 22:33:33 but to be honest in this situation I'd suggest creating a patch instead Nov 10 22:33:46 im just trying to make a quick hacked test Nov 10 22:33:48 before i finalize it Nov 10 22:33:56 its an aggravating issue thats taken me time to even locate >_< Nov 10 22:35:10 SAMA5 doesnt supported neon but does vfpv4-d16, i updated the build confs to reference this, even hacked it in places Nov 10 22:35:12 and what do you know Nov 10 22:35:16 eglibc is including NEON instructions Nov 10 22:35:30 because gcc is defining ARM_NEON just because cortexa5s can support neons OPTIONALLY Nov 10 22:35:43 SIGH Nov 10 22:35:56 *gun in mouth* Nov 10 22:36:26 so i nuked every bit of neon instructions and defines from eglibc Nov 10 22:37:12 there must be an easier way to fix it... Nov 10 22:37:34 i would need to somehow undefine __ARM_NEON__ Nov 10 22:37:37 which gets set by gcc Nov 10 22:37:53 defining -mfpu=vfpv4-d16 doesnt help Nov 10 22:38:31 "The macro __ARM_NEON__ is defined by gcc when compiling for a target that implements NEON technology" Nov 10 22:40:28 then surely tell gcc not to build for a target that supposedly supports NEON? Nov 10 22:40:41 i would like the vfp optimizations Nov 10 22:40:53 i mean Nov 10 22:40:55 the whole issue is Nov 10 22:41:01 im telling it to compile for a cortexa5 Nov 10 22:41:17 but A5s have "optional" NEON, meaning the manufacturer can leave it out Nov 10 22:41:22 and in my case, Atmel did not implement Neon Nov 10 22:41:30 in their A5s Nov 10 22:42:07 besides me telling it to use vfpv4-d16 for the fpu, there doesnt seemt o be a way to get GCC to stop defining __ARM_NEON__ Nov 10 22:42:09 globally Nov 10 22:42:57 sigh Nov 10 22:43:03 i just confirmed the issue is with that bit Nov 10 22:43:07 Atmel's old test builds Nov 10 22:43:14 were done with eglibc which did not include NEON Nov 10 22:43:19 eglibc 2.17*** Nov 10 22:43:31 eglibc 2.18 and newer include the faultly define check Nov 10 22:46:25 Messoroz: what is DEFAULTTUNE set to in your configuration? Nov 10 22:47:00 cortexa5thf Nov 10 22:48:31 alternatively cortexa9thf is also compatible Nov 10 22:48:37 i was playing between the two Nov 10 22:48:41 A9 = A5 with some tweaks Nov 10 22:55:09 i wonder if GCC's "-U" option can be used to globally delete ARM_NEON Nov 10 22:55:13 for the yocto builds Nov 10 22:58:08 Wondering if anyone can comment on the status of Qt5 toolchain on Yocto, particularly on commercial offerings (Wind River Linux et al)? Nov 10 22:58:54 Official adoption seems slow. Is it possible to deploy Qt5 applications? Is it advisable? Nov 10 23:01:17 it's not in yocto proper yet, but there's a quite functional qt5 layer available in the community. see meta-qt5. Nov 10 23:01:33 http://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/ Nov 10 23:05:49 kergoth: Thanks. I'm hoping it progresses downstream at some point... Nov 10 23:06:31 afaik that's the intent, just a matter of time **** ENDING LOGGING AT Mon Nov 11 02:59:58 2013