**** BEGIN LOGGING AT Tue Oct 20 02:59:58 2015 Oct 20 07:14:51 morning all Oct 20 07:29:04 bluelightning: good morning Oct 20 09:41:14 Hello everyone Oct 20 09:45:51 something really odd is happening here with yocto. Oct 20 09:46:35 I say MACHINE=machine-1 , but the run.do_compile scripts contain a sysroot line which points to machine-b Oct 20 09:46:48 and I get compilation errors like: cannot find -lgcc_s Oct 20 09:47:11 however, this does not happen if I build packages explicitely. only when I build an image, like core-image-base. Oct 20 09:50:20 dv__: check if MACHINE is really being set to what you think it is using bitbake -e Oct 20 09:50:35 it is Oct 20 09:50:43 I suspect stale data somewhere Oct 20 09:51:00 shouldn't be possible at that level Oct 20 09:51:19 I'll wipe it clean and retry. Oct 20 09:52:11 as always, better to mv it because if you delete we'll never track any issue down... Oct 20 09:53:42 howdy! i'm trying to build a package that among some others depends on fortran and itself-native. hence it indirectly depends on libgfortran-native, which doesn't seem to be provided. am i just missing something or does it really need to be added there, then? Oct 20 09:54:04 i remember something similar in the past. when reusing gcc accross multiple machines. Oct 20 09:54:48 gcc had absolute sysroot path hardcoded. Oct 20 09:55:24 hah, that could be it Oct 20 09:55:46 i trying to remember what the issue was.. Oct 20 09:55:54 come to think of it, it happened when I tried to build for freescale machines, and I already had built for one Oct 20 09:55:57 presumably that was before we poisoned the default directories Oct 20 09:56:01 the weird part is that this package seems to kind of half-cross-compile-aware. like, it supports configure --host, but misses that for fortran. Oct 20 09:56:20 bluelightning: yes. it was dylan timeframe Oct 20 09:56:53 dv__: which version of the build system are you building with? Oct 20 09:57:09 for the context: https://lists.linaro.org/pipermail/linaro-dev/2013-September/016692.html Oct 20 09:57:28 you mean bitbake? Oct 20 09:57:33 this is poky master Oct 20 09:58:02 hmm, then the default directories should already be poisoned Oct 20 09:58:21 I'm now retrying a clean build with that machine that caused problems earlier Oct 20 09:58:36 to be exact, I first built qemux86-64 , then nitrogen6x, then cubox-i Oct 20 09:59:12 the first one built fine, no problems. second too (except for the kernel, but that's a different, bsp specific thing). third one broke all over the place. Oct 20 09:59:20 second and third are both imx6 devices. Oct 20 09:59:42 otavio: perhaps also interesting for you ^ Oct 20 10:00:02 Hello Oct 20 10:01:24 dv__: wha tis the error? Oct 20 10:01:51 I say MACHINE=machine-1 , but the run.do_compile scripts contain a sysroot line which points to machine-b and I get compilation errors like: cannot find -lgcc_s however, this does not happen if I build packages explicitely. only when I build an image, like core-image-base. Oct 20 10:01:57 dv__: it may be poisoned .pc files or similar Oct 20 10:02:14 dv__: which recipe? Oct 20 10:02:19 a lot of them Oct 20 10:02:30 openal-soft, libeigen, libproxy to just name a few Oct 20 10:03:09 let's see if it happens again after starting a cubox-i build from scratch Oct 20 10:04:16 the order of machines (qemux86-64, nitrogen6x, cubox-i) is probably the next best way of replicating this Oct 20 10:04:48 Sure; if you reproduce it again I can surely trigger it here Oct 20 10:05:14 However O.S. Systems autobuilder uses shared tmp so I expect it would have gotten it Oct 20 10:06:03 also, here's my local.conf http://pastie.org/private/u1w6gucpsjkjbxzec0a Oct 20 10:06:41 does it also build for qemu? although that doesnt sound like a likely cause Oct 20 10:11:34 dv__: it does not; well qemu would be a non-fsl-arm machine Oct 20 10:12:39 dv__: line 17 and 18 are a problem Oct 20 10:12:55 dv__: you should not change distro features in same tmp for different machines Oct 20 10:13:07 dv__: use a single _remove condition Oct 20 10:18:46 dv__: I am building Boundar's machine to check the kernel build error Oct 20 10:18:53 alright Oct 20 10:20:25 thanks. I do wonder now though if that too was caused by some weirdness in my setup. Oct 20 10:23:14 dv__: The kernel? no, this is unlikely Oct 20 10:23:25 dv__: also, cubox one needs fixing as well, I guess Oct 20 10:24:35 yeah, thats another story Oct 20 10:24:46 in fact, this is what I was trying to check in the first place Oct 20 10:25:28 dv__: I just built kernel using gcc 4.9 Oct 20 10:25:34 dv__: now checking 5.2 Oct 20 10:27:12 dv__: ok, 5.2 fails. Oct 20 10:29:49 and you did shared tmp builds for several machines with 5.2 too? Oct 20 10:30:01 because maybe what I saw is 5.2 specific Oct 20 10:32:47 dv__: the error is gone adding: http://termbin.com/007i Oct 20 10:38:22 ah, cool. Oct 20 10:38:37 these patches are from linux-fslc? Oct 20 10:48:54 dv__: linux-imx; but similar ones are in fslc Oct 20 10:49:21 dv__: in linux-fslc we are applying the stable kernel fixes, which includes gcc fixes Oct 20 11:04:54 concerning recipe naming. if file is called XYZ_x.y.z.bb it implicitly means that its named XYZ. version x.y.z, and BBCLASSEXTENDS = "cross", right? Oct 20 11:05:52 and if i make it XYZ-{cross,native,natiesdk}_x.y.z.bb, that explicitly sets the BBCLASSEXTENDS? Oct 20 11:28:33 does anybody have a hint concerning building native fortran support? libgfortran seems to lack BBCLASSEXTEND native, in turn would depend on gcc-runtime-native... I think I am just missing some crucial point here. Oct 20 14:19:27 do you have a fix? Oct 20 14:19:39 ndec I think I am having your mesa+gc-5 sigbus issue Oct 20 14:20:32 hi Crofton|road : nothing better than this for now Oct 20 14:20:32 GCCVERSION_armv7a="4.9.3" Oct 20 14:20:39 but that works well ;-) Oct 20 14:21:02 hmm, does that imapctntire build? Oct 20 14:21:19 I put it in local.conf.. Oct 20 14:21:20 yeah, I guess it would Oct 20 14:21:23 yp Oct 20 14:21:27 bother Oct 20 14:21:46 on which platform are you getting that? Oct 20 14:21:52 I was hoping linaro had made gc5 much better for arm :) Oct 20 14:21:56 zynq Oct 20 14:22:00 dual a9 Oct 20 14:22:19 i think we have. it doesn't mean there is no bug ;-) Oct 20 14:22:27 glxgears runs, but get sigbus somewhere in mesa running app Oct 20 14:22:34 :) Oct 20 14:22:57 Crofton|road: what do you mean by 'runs'? Oct 20 14:23:16 I men glxgears works, you see the gears on screen Oct 20 14:23:40 but we ahve an sdr app fosphor that does a little gl and it blows in mesa at start up Oct 20 14:23:58 ah. i don't remember seeing it.. i initially got that failure with weston, which wouldn't start. Oct 20 14:24:09 weston uses mesa? Oct 20 14:24:15 * Crofton|road is an idiot about guis stuff Oct 20 14:24:21 yes Oct 20 14:24:45 ok Oct 20 14:25:09 sounds like I ned to rebuild with older gcc and make sure problem goes aay Oct 20 14:25:51 it will probably.. but i guess we need to figure out what the problem is with 5.x.. Oct 20 14:25:57 right Oct 20 14:26:12 I have Ettus marketing making noise about a demo this week :) Oct 20 14:26:32 I should never have shown them the usb flat panel :) Oct 20 14:26:33 i am sure they won't notice if you built with 4.9.3.. Oct 20 14:27:02 performane is sucky and I am trying to figure out exactly hy Oct 20 14:27:25 wearing an optimist hat, I was hoping for some gains with modern stuff Oct 20 14:27:35 let me know if you haveother ideas to test Oct 20 14:28:01 and I'll let you know if using older g makes my sigbus go aay Oct 20 14:28:22 Thanks for the info Oct 20 14:28:45 Crofton|road: i will paste your log on #freedreno, to see if that rings a bell there.. Oct 20 14:28:56 thanks Oct 20 14:29:26 I gdb'd a backtrace, and the code looks simple Oct 20 14:30:29 Crofton|road: btw, you use mesa for the s/w rendering, right? Oct 20 14:30:37 right Oct 20 14:30:41 no gpu on zynq Oct 20 15:55:22 Hi. is there a way to override PREFERRED_VERSION in recipes? Oct 20 15:59:26 driftingblues: you can't do it within a recipe, you can only do it at the configuration level Oct 20 16:01:51 bluelightning: You mean local.conf? Oct 20 16:02:25 driftingblues: local.conf can be used temporarily but that sort of thing usually belongs in your custom distro config Oct 20 16:03:27 bluelightning: Okay thanks Oct 20 20:47:00 ndec, backing down to gcc 4.9.3 resolved my mesa issue Oct 20 20:47:04 except for it being slow Oct 20 20:47:20 well, but that's not gcc fault i presume.. Oct 20 20:47:27 well Oct 20 20:47:36 I wish it would magically work better Oct 20 20:48:05 i would like to try gcc 5.x + mesa upstream (11.x) to see, if that makes any difference.. Oct 20 20:48:14 do you know any ways to speed up opengl on arm without a hardware accell Oct 20 20:48:35 but then we have no choice than digg into mesa dissambly.. to figure out what/how gcc breaks.. Oct 20 20:48:43 GPU on PCI? Oct 20 20:48:46 yeah Oct 20 20:48:50 hah Oct 20 20:48:52 no pci Oct 20 20:49:03 the smart guy is saying llvmpipe Oct 20 20:49:35 well not sure how faster that will be.. Oct 20 20:50:34 is it easy to try? Oct 20 20:52:00 i think so. one sec. Oct 20 20:53:20 Crofton: what do you have in mesa bbappend right now? Oct 20 20:53:36 no bbappend Oct 20 20:53:45 I suppose i need to read the recipe Oct 20 20:57:12 Crofton: you probably need to add "gallium gallium-egl gallium-gbm gallium-llvm" in PACKAGECONFIG for mesa Oct 20 20:57:27 ok Oct 20 20:57:38 I'm in recipe now Oct 20 20:57:43 thanks for the tips Oct 20 20:58:17 never did that on arm, though. Oct 20 20:58:22 :) Oct 20 21:24:31 ndec, I do not see gallium-egl and gallium-gbm as PACKAGECONFIG Oct 20 21:24:52 that might have been from an older mesa.. Oct 20 21:24:59 k Oct 20 21:25:54 Crofton: flags for EGL and GBM Gallium had been removed in 10.4, Oct 20 21:26:04 in ba079975fa984f53fde5b4e8131d0f3877323e6c Oct 20 21:26:10 ah thanks Oct 20 21:27:03 I need to learn this shit one day Oct 20 21:27:07 so many things to learn Oct 20 21:27:17 I should just play radio **** ENDING LOGGING AT Wed Oct 21 02:59:58 2015