**** BEGIN LOGGING AT Tue Jul 05 02:59:59 2016 Jul 05 09:19:33 morning Jul 05 12:20:14 heh. after so many years of avoiding buildroot I had to use it ;( Jul 05 12:24:47 condolences ;) Jul 05 12:25:49 Jin^eLD: good part is that someone wrapped it in a way that I do not have to deal with internals Jul 05 13:13:25 :) Jul 05 13:29:34 I've only used buildroot once but the curses interface is a better initial experience than YP, imo. Jul 05 13:31:02 s/YP/OE/ to be more accurate and channel appropriate. Jul 05 13:32:07 vmeson: very few people will argue that buildroot has a shallower learning curve to start with Jul 05 13:32:58 though i did enjoy a series of blog posts by a consultancy where they were trying to reduce a clients buildroot run time from "a day" by adding all sorts of custom magic, which OE has out of the box Jul 05 13:44:50 * vmeson skims BR vs YP: http://events.linuxfoundation.org/sites/events/files/slides/belloni-petazzoni-buildroot-oe_0.pdf -- BR has no package mgmt... huh. Moving on... Jul 05 14:09:10 vmeson: BR isn't intended as a feature complete alternative to YP. BR is more about minimalistic systems that tend to be fixed, with way less features, like a network connection. Jul 05 15:54:20 fray, any idea why BASELIB would be set to lib64 for the powerpc64 case? Jul 05 15:54:46 if you have multilib or LSB enabled it would be.. Jul 05 15:55:11 otherwise, it would only be set if there was a specific architectural limitation (i.e. something hard coded in the kernel or libc) Jul 05 15:55:25 this was done in bitbake.conf Jul 05 15:55:35 commit by someone at windriver Jul 05 15:56:18 not WR Jul 05 15:56:19 7a278238 meta/conf/bitbake.conf (Kumar Gala 2011-08-04 13:51:26 -0500 12) BASELIB = "lib" Jul 05 15:56:19 7a278238 meta/conf/bitbake.conf (Kumar Gala 2011-08-04 13:51:26 -0500 13) BASELIB_powerpc64 = "lib64" Jul 05 15:56:19 7a278238 meta/conf/bitbake.conf (Kumar Gala 2011-08-04 13:51:26 -0500 12) BASELIB = "lib" Jul 05 15:56:19 7a278238 meta/conf/bitbake.conf (Kumar Gala 2011-08-04 13:51:26 -0500 13) BASELIB_powerpc64 = "lib64" Jul 05 15:56:25 (oops didn't mean to paste twice) Jul 05 15:56:51 yeah Jul 05 15:56:55 hmmm Jul 05 15:57:06 I though we blamed WR for everything? Jul 05 15:57:14 people do.. but it's not us... :) Jul 05 15:57:20 Kumar worked for freescale back in 2011.. Jul 05 15:57:24 so you are free to blame them Jul 05 15:57:38 damn, I always fell bad blaming them for everything Jul 05 15:57:42 I looked last week Jul 05 15:57:53 now trying to get back to work Jul 05 15:58:04 if I had to guess, it's probably because something in glibc, or something freescale did (binaries?) had '/lib64' hardcoded into them. Jul 05 15:58:09 WHy would anyone force that for one arch? Jul 05 15:58:19 (at WR, we alsways enable the multilib code... so this stuff never runs for us) Jul 05 15:58:29 we want powerpc64 in lib64 for instance.. Jul 05 15:58:37 but we also want it controlled by the tune files Jul 05 15:58:58 Crofton|work it has to be compatibility.. I'd start with gcc or glibc from the era.. Jul 05 15:59:07 * Crofton|work curses Jul 05 15:59:09 highly likely one or the other or both expected libs in lib64 Jul 05 15:59:33 so you could build with stuff in lib, but would expect runtime to fail? Jul 05 15:59:46 I have certainly seen cases of that in the past.. Jul 05 15:59:51 especially on 64-bit systems Jul 05 16:00:43 arch's like PPC, they were never inteded for PPC64 ABI to be the primary on the system, it was desinged 32-bit would be with 64-bit capable ABI libraries and programs for things that needed big memory.. Jul 05 16:00:47 otherwise it was just 'wasteful' Jul 05 16:02:12 I've been tryin gto help a guy get an older build and add gnuradio, but look slike he is falling over a bug in gnuradio cmake that doesn't see lib64 Jul 05 16:02:25 (and I think qwt has the same issue) Jul 05 16:02:49 and trying to get back to /lib still has build failures at his end Jul 05 16:02:58 I suspect bad shit in layers I can't see Jul 05 16:03:14 Thanks for the info Jul 05 16:03:25 ya.. I've not tried a '/lib' PPC64 build in a very very long time.. sorry Jul 05 18:58:43 ppc64 always assumed /lib64 since its standard config is to support biarch Jul 05 19:00:01 do you think it would work with /lib, was trying to work around some other bugs :) Jul 05 19:00:47 Most probably no. since gcc has assumptions Jul 05 19:04:06 but it seems gnuradio's cmake system needs fixing Jul 05 19:04:21 are you having issues installing it ? Jul 05 19:04:45 older gnuradio installed volk into lib not lib64, so packaging fail Jul 05 19:05:14 trying to avoid fixing something old and hoping fixed in new :) Jul 05 19:06:19 may be you can tweak INSTALL_LIB_DIR from recipe Jul 05 19:06:55 should be easy once you spot the variable controlling the installation of this volk lib Jul 05 19:11:20 well, this is an older version, need to check with later **** ENDING LOGGING AT Wed Jul 06 02:59:58 2016