Wednesday, 2018-11-28

*** Crofton|work <Crofton|work!~Crofton@> has joined #yocto00:13
robbawebbahello, quick question: Is it possible to determine the value of MACHINE for a running image on a target? Whether it's an environment variable, /etc file, or some other mechanism?00:29
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto00:37
*** sajjad_ <sajjad_!~sajjad@> has joined #yocto00:54
*** xtron <xtron!~sajjad@> has quit IRC00:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:03
*** nerdboy <nerdboy!> has joined #yocto01:08
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto01:08
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:38
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto01:38
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC01:54
khemrobbawebba: these are build time variables, they do not have much bearings on real target when running but generally output of `hostname` is same as MACHINE01:54
khembut thats not hard and fast rule01:55
*** sgw <sgw!~sgw@> has quit IRC03:00
*** sgw <sgw!~sgw@> has joined #yocto03:02
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto03:15
*** lukma <lukma!> has quit IRC03:19
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC03:30
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC03:32
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto03:33
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC03:43
*** lukma <lukma!> has joined #yocto03:45
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto04:09
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC04:13
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC04:19
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto04:20
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto04:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC04:28
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto04:34
*** dreyna_ <dreyna_!> has quit IRC04:36
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC04:55
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto04:58
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto05:03
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC05:12
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto05:15
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC05:19
*** hundeboll <hundeboll!> has quit IRC05:35
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC05:35
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-lwfuxliqwjdgzeux> has quit IRC05:41
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-qxicyplcidouphsy> has joined #yocto05:43
*** suy <suy!> has joined #yocto05:44
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has joined #yocto05:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto05:56
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC06:05
*** pouet_fo1 <pouet_fo1!~nico@> has joined #yocto06:05
*** pouet_forever <pouet_forever!~nico@> has quit IRC06:07
*** AndersD <AndersD!> has joined #yocto06:11
*** AndersD <AndersD!> has quit IRC06:21
*** AndersD <AndersD!> has joined #yocto06:22
*** seebs <seebs!~seebs@> has quit IRC06:25
*** interruptguy <interruptguy!> has joined #yocto06:28
*** hamis <hamis!~irfan@> has joined #yocto06:32
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:40
*** seebs <seebs!~seebs@> has joined #yocto07:09
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto07:22
*** gtristan <gtristan!~tristanva@> has joined #yocto07:23
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC07:25
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto07:26
*** frsc <frsc!> has joined #yocto07:29
*** tprrt <tprrt!~tprrt@> has joined #yocto07:29
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC07:31
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto07:32
*** lusus <lusus!~lusus@> has joined #yocto07:33
*** TobSnyder <TobSnyder!> has joined #yocto07:34
*** Carton__ <Carton__!~jo@> has joined #yocto07:38
*** Carton__ <Carton__!~jo@> has left #yocto07:40
*** dreyna <dreyna!> has joined #yocto07:40
*** Bunio_FH <Bunio_FH!> has joined #yocto07:41
*** radsquirrel <radsquirrel!> has quit IRC07:54
*** fl0v0 <fl0v0!> has joined #yocto07:57
*** robertmarshall <robertmarshall!> has joined #yocto08:09
*** radsquirrel <radsquirrel!> has joined #yocto08:09
*** sagner <sagner!~ags@> has joined #yocto08:11
pepijndevosAlright, I'm back at it again... still trying to get a binary native package into my sysroot. Everything indicates this should be really easy, but nothing works.08:13
*** pouet_fo1 <pouet_fo1!~nico@> has quit IRC08:15
pepijndevosI'm now trying ton install all the files in ${D}${datadir}, because datadir is in SYSROOT_DIRS. But nothing happens...08:16
*** robertmarshall <robertmarshall!> has quit IRC08:16
*** pouet_forever <pouet_forever!~nico@> has joined #yocto08:16
pepijndevosIt now installs into ./tmp/work/x86_64-linux/dds-native/5.3.1-r6/image/home/rove/code/poky/rpi-build/tmp/work/x86_64-linux/dds-native/5.3.1-r6/recipe-sysroot-native/usr/share/rti_connext_dds-5.3.108:17
*** gtristan <gtristan!~tristanva@> has quit IRC08:19
*** mckoan|away is now known as mckoan08:20
pepijndevosHmmm, getting closer08:26
*** dreyna <dreyna!> has quit IRC08:31
*** interruptguy <interruptguy!> has quit IRC08:35
*** interruptguy <interruptguy!> has joined #yocto08:36
*** gtristan <gtristan!~tristanva@> has joined #yocto08:42
*** radsquirrel <radsquirrel!> has quit IRC08:44
*** cvasilak <cvasilak!> has joined #yocto08:48
pepijndevosOk, it kinda works. More details...08:50
pepijndevosRight now I symlink the binaries into bindir so they are found, and then I use readlink -f $(which rtipkginstall) to find their actual location so I can run them without failures.08:52
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto08:59
pepijndevoscool, this works nicer export NDDSHOME=${STAGING_DIR_NATIVE}/usr/share/rti_connext_dds-${PV}09:00
*** anujm <anujm!~anujm@> has joined #yocto09:01
*** cvasilak <cvasilak!> has quit IRC09:02
pepijndevosWARNING: dds-native-5.3.1-r6 do_populate_sysroot: File 'somebinary' from dds-native was already stripped, this will prevent future debugging!09:03
*** cvasilak <cvasilak!> has joined #yocto09:04
*** kristoiv <kristoiv!~kristoiv@> has quit IRC09:06
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto09:08
*** varjag <varjag!> has joined #yocto09:10
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:11
*** georgem <georgem!~georgem@> has quit IRC09:12
*** georgem <georgem!~georgem@> has joined #yocto09:12
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC09:17
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto09:18
*** rfried <rfried!~rfried@> has left #yocto09:26
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC09:26
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has joined #yocto09:28
*** dheeraj <dheeraj!~Thunderbi@2001:df0:d300:4:903e:b3ef:c95d:394b> has quit IRC09:28
*** florian_kc is now known as floian09:30
*** floian is now known as florian09:30
T_UNIXwhat's the supposed way to unset a `PREFERRED_PROVIDER`?09:31
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:32
LetoThe2ndT_UNIX: not setting it, in the first place.09:32
T_UNIXit's set by some `.inc` of another layer :-/09:33
LetoThe2ndT_UNIX: does that sentence virtually continue with "... pulled in by a premade DISTRO or MACHINE i use"?09:33
T_UNIXmore or less ;-D09:34
LetoThe2ndbecause in that very common case, your answer is: create a custom MACHIEN or DISTRO based off that one, and adjust it to your needs.09:34
T_UNIXthat's what I already did09:34
LetoThe2ndthen you're doing it wrong.09:35
T_UNIXI'm reusing that `.inc`, yet it's a single line that is "unwanted"09:35
LetoThe2ndthen don't reuse it. if its in a layer you don't control, then you will run into troubles anyways if somebody updates it for reasons beyond your likings.09:36
LetoThe2ndcopy it over to your layer, nail it down.09:36
T_UNIXthat's what I do by using git.09:36
T_UNIXbut I got your point09:36
LetoThe2ndwell you asked for the recommended way :-)09:37
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:37
LetoThe2ndthe technically possible way is: overwrite it after the include.09:37
T_UNIXthank you :)09:37
LetoThe2ndbut i explicitly discourage that.09:37
T_UNIXLetoThe2nd: yeah, that's what I just did. But I'll amend that to go the recommended way.09:37
*** anujm <anujm!~anujm@> has quit IRC09:39
*** kaspter <kaspter!~Instantbi@> has quit IRC09:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:56
*** rburton <rburton!> has joined #yocto09:58
*** Bunio_FH <Bunio_FH!> has quit IRC10:09
*** Bunio_FH <Bunio_FH!> has joined #yocto10:10
LetoThe2ndhas anybody here run into the situation that open() on target always aborts with EPERM, and doesn't even make to strace, while the same come works nicely on the dev host? usual reasons as uid tinkering and O_NOATIME flags don't apply.10:13
rburtonwell that sounds broken in a really special way10:13
LetoThe2ndhooray. :-(10:14
LetoThe2ndcould at least kinda understand it if it was limited to a specific, maybe special filesystem. but it now fails always, even in tmpfs10:15
rburtonhow does *anyting* work if open() fails?10:15
LetoThe2ndrburton: the fun part is that the system seems to work fine. just my current dev task which i deploy through devtool fails.10:16
*** kanavin <kanavin!~kanavin@> has quit IRC10:24
*** kanavin <kanavin!~kanavin@> has joined #yocto10:25
pepijndevoscan i somehow get the version of a dependency?10:26
LetoThe2ndpepijndevos: hum, whats the usecase?10:33
*** kristoiv <kristoiv!~kristoiv@> has quit IRC10:33
pepijndevosLetoThe2nd, the package installed into somedir-<version>, so now I want to refer to that directory10:38
LetoThe2ndsounds like a broken install process.10:39
*** berton <berton!~berton@> has joined #yocto10:39
pepijndevoswell... it's a binary installer that you can give a prefix that it then adds its version number to. I guess I could manually rename it afterwards...10:40
LetoThe2ndi'd just symlink it to a known place.10:40
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC10:43
*** berton <berton!~berton@> has quit IRC10:43
*** berton <berton!~berton@> has joined #yocto10:45
*** demonimin <demonimin!~demonimin@> has joined #yocto10:46
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto10:46
pepijndevosLetoThe2nd, everything breaks horribly when i do that. It's just horrible software I'm installing.10:48
* LetoThe2nd shrugs.10:48
LetoThe2ndi'd by now make a summary of your time wasted on that and present it to your supervisor. and get an absolutely explicit "ok, we're gonna waste lots of time there, but we totally want it, you're covered, and its not your fault"10:50
pepijndevosI'll just hardcode the version...10:51
LetoThe2ndi mean, this won't be the last fun time with that.10:51
pepijndevosFor sure10:52
rburtoncan't you glob at the relevant place?10:52
pepijndevosI'l spare you the details of compiling this on android haha weeks of my life I'll never get back.10:52
pepijndevosNot sure... worth a shot (re glob)10:54
*** JaMa <JaMa!~martin@> has quit IRC10:55
pepijndevosWe already have the whole system working on RTI and Raspbian, so while we wait for the delivery of new hardware, I'm just trying to improve this hand-rolled Raspbian setup a bit.10:58
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:59
LetoThe2ndpepijndevos: i actually pitched a paper to a conf here, on why starting your iot development on raspi+raspbian is a stupid idea in the vast majority of cases :-P10:59
pepijndevosI'd love to share that with my supervisor haha11:00
LetoThe2ndpepijndevos: if they accept it, i'll share. its german, though. feel free to hire me for an english version :)11:01
pepijndevoss/iot/robots with rotating blades/11:01
LetoThe2ndwell its a iot conf, hence the concept.11:02
LetoThe2ndthe core message actually should read like: "if you want a real product, do not start on a tinkering board using tinkering ways."11:03
*** robertmarshall <robertmarshall!> has joined #yocto11:03
*** sajjad_ <sajjad_!~sajjad@> has quit IRC11:06
*** xtron <xtron!~sajjad@> has joined #yocto11:07
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto11:08
rburtonLetoThe2nd: or if you're going to prototype on a tinker board, be aware that is the one to throw away11:14
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:14
rburtonnothing wrong with prototyping, learning, throwing away and starting again11:14
rburtonjust be aware that is a valid plan and don't expect to go from tinker to production11:14
LetoThe2ndrburton: thats why its "if you want a product"11:15
LetoThe2ndits fine if you want a) fun b) a one-off thing c) a prototype... whatever11:15
LetoThe2ndbut not, "a product"11:15
rburtoni'd like to see this presentation in english :)11:17
pepijndevosI'm kind of working on a demo/protoype... but someone might say, hey this seems to work, lets put it in production... which will make me sad.11:21
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC11:21
rburtonRP: overnight master passed selftest!11:21
rburtonso clearly you broke it more with next11:22
pepijndevosmeanwhile my recipe complains it's installing some directory that I have no idea where it comes from11:22
RPrburton: overnight master only runs on selftest, "full" runs five11:23
rburtonfake news11:23
RPrburton: gah, just dont, please ;-)11:24
rburtonwell the cpio thing replicated on debian so we can't call it a suse thing11:24
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:24
RPrburton: and I ruled out files changing :/11:24
rburtonoh how did you do that?11:25
RPrburton: also the bitbake not starting replicated and the logs don't so anything so the new debugging didn't help :(11:25
RPrburton: I replied on list, have a a hacky patch:
RPbut it proves the files don't change11:25
rburtonyou verified that code works right11:26
LetoThe2ndsorry for the halfway angry ML post, but that guy really is getting on my nerves. it was about time to vent.11:26
* rburton runs to list11:26
LetoThe2ndrburton: re presentation, throw money!11:26
RPrburton: patch has a foo.txt which shows it does11:27
LetoThe2ndhm actually, it would be interesting for an OE user summit.11:27
pepijndevosI'll read it in german11:27
rburtonRP: ah, yes.   i like that code, tidy it up and submit.  lovely sanity test for dirs which shouldn't change.11:28
*** robertmarshall is now known as rajm11:28
RPLetoThe2nd: which list was this? I could do with something to cheer me up ;-)11:29
RPrburton: I wondered if we should make it a feature11:29
rburtonRP: i wonder if any of the machines that cpio is crashing on have abort catchers on that are harvesting the cpio segfaults11:29
pepijndevosthe recipe that used to work is now going from bad to worse for some reason... like... how did I get so in my -dev package -.-11:29
LetoThe2ndRP: yocto general11:29
*** kanavin <kanavin!~kanavin@> has quit IRC11:29
RPrburton: I sadly doubt the core would be preserved11:29
*** kristoiv_ <kristoiv_!~kristoiv@> has joined #yocto11:29
*** kanavin <kanavin!~kanavin@> has joined #yocto11:29
LetoThe2ndRP: my cheering up now: lunch.11:30
*** kristoiv <kristoiv!~kristoiv@> has quit IRC11:32
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC11:35
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto11:42
rburtonRP: so the new parallel sefltest11:46
rburtonRP: each test gets a new unique build directory right?11:46
RPrburton: each parallel process11:52
rburtonso there are N build dirs for the level of parallelism and they are reused11:53
RPrburton: correct11:53
RPrburton: just realised that watchdir patch is bust, its not recursive :/11:53
rburtonrace: you fix the test and i'll finish my directory churn hack!11:54
* RP did however just figure out the mystery runqemu duplicate log messages, something that has bugged me for a long time11:54
*** toanju <toanju!~toanju@> has joined #yocto11:54
RPrburton: game on :)11:57
RPrburton: do_image does change files, nothing else showing up12:00
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC12:03
RPrburton: just needed an os.walk adding12:05
rburtonwell i have a cpio erroring out because files disappeared or changed, but not segfaulting12:06
RPrburton: which is more what you'd expect12:08
RPrburton: am I right in thinking we use cpio from the host for this?12:08
rburtoni believe so12:09
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto12:09
RPcpio-native is required by testimage12:10
rburtonyeah was just looking there12:10
rburtonis that enabled during selftest though?12:10
pepijndevosI'm confused...12:12
pepijndevos-dev package contains non-symlink .so: dds-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/dds/5.3.1-r1/packages-split/dds-dev/usr/lib/'12:12
RPrburton: It could have been installed by a previous test I guess12:13
rburtonpepijndevos: most likely because this software shipped unversioned libraries12:13
rburtonwhich is bad practise12:13
pepijndevosoooh, I remember that. Yea, this things is bad practice stacked on bad practice haha12:14
rburtonRP: replicated on demand!12:17
rburtonyeah its cpio-native12:17
rburtoni wonder how we broke that!12:17
rburtonRP: can you reproduce please?  do_image_cpio[depends] += "cpio-native:do_populate_sysroot" to image_types, add cpio to IMAGE_FSTYPES, build something12:18
rburtoni bet one of the cve patches we got actually broke cpio12:18
rburtonshall grab a second coffee and sort12:19
RPrburton: oddly enough I couldn't get that to crash here12:19
rburtonok well i made it crash once, lets try again12:19
rburtonand maybe i have a coredump to help12:19
RPrburton: I suspect its distro specific12:20
RPrburton: but anything reproducing is good12:20
RPrburton: I tried a couple of different ways and cpio-native works here (on ubuntu)12:21
RPrburton: certainly bitbake XXX-image -c testimage in an earlier test would have put it in the sysroot and it wouldn't get removed12:22
rburtoni wonder what the impact of a clean builddir per test will be :)12:22
RPrburton: huge amounts of sstate extraction12:23
rburtonwell, yeah12:24
rburtonthat's nice and fast :)12:24
RPbreaking cpio would be an achievement12:25
*** lukma <lukma!> has left #yocto12:27
pepijndevosIs there an easy way to figure out what to put in RDEPENDS to satisfy the QA errors I'm getting? Very common stuff like libc, libdl, libm, libstdc++12:28
*** radsquirrel <radsquirrel!> has joined #yocto12:34
pepijndevosI added RDEPENDS_${PN} = "libstdc++", but nothing changes. Is this also a problem with versioned .so?12:37
*** guillaumekh <guillaumekh!5a5674df@gateway/web/freenode/ip.> has joined #yocto12:37
*** radsquirrel <radsquirrel!> has quit IRC12:38
*** ClmentAubin[m] <ClmentAubin[m]!caubinmatr@gateway/shell/> has joined #yocto12:39
*** radsquirrel <radsquirrel!> has joined #yocto12:40
rburtonpepijndevos: hm it should have found those for you12:40
rburtonRP: make it log more, stops segfaulting12:41
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:41
*** gtristan <gtristan!~tristanva@> has quit IRC12:41
guillaumekhMmmh how does one set ownership on a file during do_install ? I've tried using the user & group number (e.g `install -o 1000 -g 1000 -m 755 path/to/file) but file then shows up as owned by 0(root)12:42
pepijndevosOh... maybe I know... would it fail if the .so is not for the same architecture? Confession: because RTI disabled our Raspberry Pi target, I've been using the Android target for testing the basic recipe. Maybe this is where I actually just need the proper raspi files...12:43
LetoThe2ndpepijndevos: QA barfs if the arch does not match. not sure about the ABI, but i wouldn't rule it out.12:44
*** kuzulis <kuzulis!~Denis@> has joined #yocto12:45
pepijndevosAnother fun challenge down the road is that the rpi target is built with gcc 4.7 and C++11 so linking will break anyway until I solved that by either asking RTI for a new target, or changing yocto compiler flags or compiler version.12:48
kuzulisHi guys. I want to upgrade my layers to new versions (e.g. to new branch sumo).. But now I have an troubles, like: ERROR: Nothing PROVIDES 'libgal-imx' ...  Close matches:12:48
kuzulis  libgxim12:48
kuzulis  imx-gpu-viv RPROVIDES libgal-imx ... A full log here:
kuzulisHow to solve this issue?12:48
LetoThe2ndkuzulis: find out why imx-gpu-viv is not buildable, by the looks of it.12:50
pepijndevos(yea, I hacked the recipe to copy my already installed Rpi target and that passes QA... so just keep begging RTI I guess)12:51
kuzulisLetoThe2nd: Do I need to add this 'imx-gpu-viv' recipe e.g to IMAGE_INSTALL_append ?12:54
LetoThe2ndkuzulis: no, dependencies should pull it in. the question is, why isn't it buildable (thats how i interpret it)12:55
RPrburton: but you can reproduce the segv?12:56
yoctiNew news from stackoverflow: How to flash Yocto Images directly using clonezilla <>12:57
kuzulisLetoThe2nd: What commands I need to enter to search that?12:58
pepijndevosAaaalmost there. My CMake project installs settings in etc, but these end up in /usr/etc and cause QA errors.12:58
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto13:02
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto13:02
rburtonRP: sometimes13:02
*** voidead26 <voidead26!~voidead@> has joined #yocto13:02
pepijndevosah, solution:
rburtonpepijndevos: yes please use that13:04
kuzulisLetoThe2nd: I have entered: bitbake-layers show-recipes | grep imx-gpu-viv and see that imx-gpu-viv is present..13:05
LetoThe2ndkuzulis: look at the recipe if it has a COMPATIBLE_MACHINE or something like it13:06
kuzulisLetoThe2nd: I see COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)"13:07
LetoThe2ndkuzulis: and do you have one of those?13:07
*** kaspter <kaspter!~Instantbi@> has quit IRC13:09
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:10
kuzulisLetoThe2nd: I use apalis-imx613:10
LetoThe2ndkuzulis: well then, theres your answer.13:10
LetoThe2ndappend it and add that to the compatible machines13:11
kuzulisLetoThe2nd: Hmm.. but for previous layes version, same recipe 'imx-gpu-viv' contains similar COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl)" ... And it does work.13:15
kuzulisLetoThe2nd: Where apalis-imx5.conf machine has following text: MACHINEOVERRIDES =. "mx6:mx6q:"13:17
kuzulisLetoThe2nd: s/apalis-imx5/apalis-imx613:17
LetoThe2ndkuzulis: ok, at the point its beyond my knowledge, sorry.13:18
kuzulisSo, nobody can help ? :(13:19
*** cquast <cquast!~cquast@> has joined #yocto13:37
T_UNIXkuzulis: the `OVERRIDES` variables describe which variables' priority. Read the documentation on it :)13:40
pepijndevosI have a few robots that have slightly different software. Should those be their own layer or just recipes and different images?13:42
T_UNIXkuzulis: then examine the output of `bitbake -e imx-gpu-viv`. Look at the evaluation of `COMPATIBLE_MACHINE`.13:42
T_UNIXpepijndevos: depends on how they differ. Devicetree? Kernel? Single Binaries? The way something is compiled? Image?13:44
kuzulisT_UNIX: bitbake -e imx-gpu-viv | grep ^COMPATIBLE_MACHINE shows that it is: COMPATIBLE_MACHINE="(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)"13:47
pepijndevosT_UNIX, just one different package and its deps. One uses wiringpi, one something else.13:48
kuzulisT_UNIX: That is correct for apalis-imx6, because apalis-imx6 is same as  "mx6:mx6q:"13:48
yatesrburton: was your intention (i.e.., with binconfig_xyz) that all crossscripts would be placed in the /usr/bin/crossscript folder and that folder would be in the path, and that the proper "version" of the script (whether cross build or target build) is placed in that folder for staging or packaging, respectively?13:50
T_UNIXkuzulis: and that matches the `PACKAGE-ARCHITECTURE` (cannot recall the precise variable name)?13:50
T_UNIXpepijndevos: if each software would technically be compatible with any machine, use a different image13:51
kuzulisT_UNIX: Where is PACKAGE-ARCHITECTURE ?13:52
T_UNIXkuzulis: In the package's recipe13:53
T_UNIXit's called `PACKAGE_ARCH`13:53
yatesor did you intend to put relative symlinks to each script in /usr/bin, so that they work no matter where /usr/bin/crossscript is located, and the PATH can remain standard?13:54
yatesor something else? ;)13:55
kuzulisT_UNIX: There are no PACKAGE_ARCH, in that *.bb file13:56
kuzulisT_UNIX: (nor in new layer branch, nor in previous layer branch)13:58
pepijndevoscool thanks13:59
T_UNIXkuzulis: examine the output of `bitbake -e imx-gpu-viv`. It could be in some `.inc`, some `.bbappend` or in some distribution/machine configuration.13:59
*** maudat <maudat!~moda@> has quit IRC14:02
kuzulisT_UNIX: bitbake -e imx-gpu-viv | grep PACKAGE-ARCH has an empty output14:02
kuzulisT_UNIX: oops, sorry14:03
T_UNIXkuzulis: what does `bitbake imx-gpu-viv` complain about? Maybe examine the entire output instead of greping for partial words that might be incorrect?14:03
kuzulisT_UNIX: PACKAGE_ARCH="cortexa9hf-neon-mx6qdl"14:03
kuzulisPACKAGE_ARCHS="all any noarch armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp armv7at2hf-vfp armv7ahf-neon armv7at2hf-neon cortexa9hf-vfp cortexa9hf-neon cortexa9t2hf-vfp cortexa9t2hf-neon cortexa9hf-neon-mx6qdl cortexa9t2hf-neon-mx6qdl apalis_imx6"14:03
yatesis the sysroot for a build under ${B}?14:05
derRichardis it known that gpgme does not build? (sumo)14:05
derRichardthe configure script does not find libgpg-error14:05
RPderRichard: it definitely builds on the autobuilder14:06
derRichardRP: hmm.14:07
derRichardjust tried with both arm and x86 targets14:07
yatesderRichard: does the gpgme recipe have libgpg-error (or some recipe providing it) in its DEPENDS?14:07
derRichardyates: yes, it does.14:08
kuzulisT_UNIX: Any other suggestions? :)14:08
*** goliath <goliath!> has joined #yocto14:08
*** marka <marka!~masselst@> has joined #yocto14:09
*** hamis <hamis!~irfan@> has quit IRC14:09
T_UNIXas I said: `bitbake imx-gpu-viv` look why it fails. Does it fail?14:09
RPderRichard: What changes do you have on top of standard sumo?14:09
*** interruptguy <interruptguy!> has quit IRC14:10
derRichardRP: just my layer. i didn't change gpgme at all14:10
*** iokill <iokill!~dave@> has joined #yocto14:11
derRichardlet me read the config.og14:11
derRichardmaybe the configure script is just stupid and the root cause is something different14:12
RPderRichard: we do disable a lot of the gnupg -config scripts and differ from upstream there but it should autoreconf and handle that, we do test it on the autobuilders14:12
derRichardconfigure:22254: $PKG_CONFIG --exists --print-errors "gpg-error >= $min_gpg_error_version"14:13
derRichardRequested 'gpg-error >= 1.24' but version of gpg-error is 1.1814:14
derRichardnow things get interesting14:14
derRichardhmm, makes no sense14:14
* derRichard checks layers again14:14
derRichardmeh, somebody copied an old gpg-error recipe into the customer's layer14:16
yatesyates: it depends on yocto version. for morty, it is not, it is under ${TMPDIR}/sysroots14:16
RPderRichard: that would explain it14:20
derRichardRP: yes :-(14:21
* derRichard needs to review that layer14:21
*** Crofton|work <Crofton|work!~Crofton@> has quit IRC14:25
*** toanju <toanju!~toanju@> has quit IRC14:35
kuzulisT_UNIX: > `bitbake imx-gpu-viv` look why it fails. Does it fail?14:36
kuzulisT_UNIX: It compiles successfully14:36
kuzulisT_UNIX: It fails only then I build image:14:36
kuzulisERROR: Nothing PROVIDES 'libgal-imx' (but /mnt/data/Yocto-miatech/yocto-miatech/sources/meta-freescale/recipes-graphics/xorg-driver/ DEPENDS on or otherwise requires it). Close matches:14:36
kuzulis  libgxim14:36
kuzulis  imx-gpu-viv RPROVIDES libgal-imx14:36
LetoThe2ndkuzulis: PROVIDES != RPROVIDES14:37
LetoThe2ndkuzulis: sounds like somewhere the dependency structure was modified14:37
kuzulisand? what I need to do here? :)14:39
kuzulisI did not change anything14:39
*** Zajc <Zajc!> has quit IRC14:39
kuzulisI just update a layers from pyro to sumo14:39
LetoThe2ndkuzulis: if i had to guess, then i'd say that you only updated one or a couple of your layers in use, but not all of them14:40
kuzulisLetoThe2nd: I have updated all layers, exclude qt4/5 layers:
LetoThe2ndkuzulis: heh its nice that you show such detailed information, but i actually do not know by just looking at git commit hashes which states of the layers those are.14:44
*** kaspter <kaspter!~Instantbi@> has quit IRC14:44
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:45
kuzulisLetoThe2nd: I taked this hashes from:
kuzulisLetoThe2nd: I  hope that that a true hashes :)14:47
LetoThe2ndkuzulis: sorry, i'll actually not dig there further. i'm just saying, something obviously first DEPENDED in it, and it PROVIDES. thats ok. now it changed from PROVIDES to RPROVIDES, but the recipe that DEPENDed did not change. so, thats where you have to go hunting.14:48
kuzulisLetoThe2nd: Ohhh.. many thanks, anyway :(14:53
kuzulisLetoThe2nd: Then, is any workariunds for this, witchout of modifing os a source layers (not my layers)?14:55
LetoThe2ndkuzulis: that would be then reporting to upstream.14:55
*** armpit <armpit!> has quit IRC14:56
*** Crofton|work <Crofton|work!> has joined #yocto14:57
*** armpit <armpit!> has joined #yocto14:58
kuzulisLetoThe2nd: Nono, I mean, is it possible to fix it without of modifing of a provided (not my) layers?14:59
kuzulisLetoThe2nd: to do not touch that layers?14:59
LetoThe2ndkuzulis: can definitively say. but probably no.14:59
*** JaMa <JaMa!~martin@> has joined #yocto15:03
*** AndersD <AndersD!> has quit IRC15:03
kuzulisLetoThe2nd: I see in latest imx-gpu-viv*.inc file this:15:05
kuzulisPROVIDES += " \15:05
kuzulis    imx-gpu-viv \15:05
kuzulisRPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv"15:05
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC15:06
kuzulisLetoThe2nd: Ahh, sorry, I see: RPROVIDES_libgal-imx += "libgal-imx"15:09
*** Zajc <Zajc!> has joined #yocto15:09
kuzulisLetoThe2nd: but when I see to previous 'imx-gpu-viv*.inc' file, then there are no any mentions of 'libgal-imx'15:11
*** no_such_user <no_such_user!> has joined #yocto15:16
kuzulisLetoThe2nd: Hmm... no... I'm confused.. I see that a newest 'imx-gpu-viv*.inc' file contains: PROVIDES += " \15:16
kuzulis    imx-gpu-viv \15:16
kuzulis    libgal-imx \15:16
kuzulisbut why bitbake say that " Nothing PROVIDES 'libgal-imx' " ?15:17
kuzulisLetoThe2nd: Also this file contains and: RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv"15:20
kuzulisLetoThe2nd: So, maybe I need to remove this RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" ?15:21
*** varjag <varjag!> has quit IRC15:23
yatesi'm baffled15:35
*** alpha <alpha!> has joined #yocto15:36
*** TobSnyder <TobSnyder!> has quit IRC15:39
yatesnm, ok, i'm good15:41
pepijndevosYeaaah. Linking errors due to ABI changes in C++11 between gcc 4.x and 5.x. Until RTI comes up with a newer target, my options are basically: make everything that depends on RTI use _GLIBCXX_USE_CXX11_ABI or compile them with gcc 4.x15:44
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto15:45
pepijndevosWill poky be fine if I just do GCCVERSION="4.7.%" in local.conf or is that too ancient? And is there an easy way to pass _GLIBCXX_USE_CXX11_ABI from the (cmake) recipe?15:48
LetoThe2ndpepijndevos: it will do, if a recipe actually provides that version15:49
pepijndevosSeems like poky itself only has 8.2 and 7.3. Neeever mind then. I'll go the _GLIBCXX_USE_CXX11_ABI route. Or just do nothing and wait for RTI, they already told me that they have a newer target, they just haven't given it to me yet.15:51
*** cvasilak <cvasilak!> has quit IRC15:53
yateswhy does specifying the -pthread option to a gcc link error out?15:54
yatescorrection: a g++ link15:55
georgemwell, something looks messed up because it's looking in the wrong path15:55
yatesif i omit the -pthread option and just use -lpthread, it works fine15:56
georgemcould be a toolchain problem15:57
yoctiNew news from stackoverflow: am335x evmsk screen init:id"00" respawning too fast disabled for 5 minutes yocto sumo <>15:57
*** armpit <armpit!> has quit IRC16:03
*** lazyape <lazyape!> has quit IRC16:10
*** lazyape <lazyape!> has joined #yocto16:10
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:11
*** dreyna <dreyna!> has joined #yocto16:12
*** tprrt <tprrt!~tprrt@> has quit IRC16:14
*** pouet_forever <pouet_forever!~nico@> has quit IRC16:14
*** kristoiv_ <kristoiv_!~kristoiv@> has quit IRC16:15
*** kuzulis_ <kuzulis_!~Denis@> has joined #yocto16:16
*** kuzulis_ <kuzulis_!~Denis@> has quit IRC16:19
*** kuzulis <kuzulis!~Denis@> has quit IRC16:20
yatesright. thanks georgem16:20
*** rajm <rajm!> has quit IRC16:44
*** yann <yann!> has joined #yocto16:47
yateswhat is the difference between the sysroot-destdir, build, and image subdirectories under <build>/tmp/work/<arch>/${PN}/${PV}-${PR} ?16:48
yatesobviously build is when building the recipe. what about the others16:49
yatesat what stage in the build process are the others used?16:50
aehs29rburton: I sent some patches to the python manifest to add comments last week, is there a reason why they haven't been merged yet?, I havent seen them in your contrib branches either, thats why I ask16:50
*** lusus <lusus!~lusus@> has quit IRC16:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:56
T_UNIXdamn. `COPY_LIC_DIRS`. somhow broke when I removed a package that used to be a PREFERRED_PROVIDER. For some reason bitbake still wants to handle its license :-/17:05
*** kristoiv <kristoiv!> has joined #yocto17:06
*** fl0v0 <fl0v0!> has quit IRC17:06
T_UNIXI mean I even `BBMASK`ed the file/package that is now apparently - according to `license.bbclass`' `license_create_manifest`- missing.17:08
*** alpha <alpha!> has quit IRC17:14
*** Bunio_FH <Bunio_FH!> has quit IRC17:16
*** kristoiv <kristoiv!> has quit IRC17:16
T_UNIXit somehow comes up witht that via `runtime-reverse/$NOLONGEREXISTINGPACKAGE`17:16
*** goliath <goliath!> has quit IRC17:21
rburtonaehs29: probably forgot to tag them17:22
rburtonaehs29: will sort17:22
rburtonyates: image is used when building a package too17:22
rburtonyates: build/ is the build tree for out-of-tree buids17:22
rburtonyates: image/ is where install installs too17:23
rburtonsysroot-destdir is the bits from image that are for the sysroot17:23
rburtonthen there's package/ which is the bits from image for the packages17:23
rburtonand then packages-split which is package, but split per-package17:23
rburton(grep can tell you this if you search for ${WORKDIR}/image, etc)17:23
rburtonover meta/classes/17:23
T_UNIXwhere does that `ipk/` package management get its information from? How does it build its store?17:26
*** clementben <clementben!> has joined #yocto17:28
*** clementben is now known as clement_17:28
*** clement_ is now known as clement__17:28
*** clement__ is now known as clementben17:28
T_UNIXthat was the culprit: obsolete packages in `deploy/ipk` lead to them retroactively corrupting the build17:30
*** stephano <stephano!stephano@nat/intel/x-tghrxmrudbhaoieu> has joined #yocto17:46
*** WillMiles <WillMiles!> has joined #yocto17:46
*** frsc <frsc!> has quit IRC17:58
*** sagner <sagner!~ags@> has quit IRC18:00
*** rewitt1 <rewitt1!~rewitt@> has joined #yocto18:02
*** moto-tim1 <moto-tim1!~ttorling@> has joined #yocto18:02
*** rewitt <rewitt!~rewitt@> has quit IRC18:02
*** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has quit IRC18:02
yatesi can see a library (namely, under <build>/tmp/sysroots/<macharch>/usr/lib, but my link is not finding ti18:08
yates| /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find -lwx_gtk2u_aui-3.0-arm-fslc-linux-gnueab18:09
yatesdo i need a special -L<path>?18:09
yatesah, ok, thanks rburton18:10
*** scottrif <scottrif!> has joined #yocto18:11
*** dmoseley <dmoseley!> has quit IRC18:11
*** dmoseley <dmoseley!> has joined #yocto18:12
*** JSwede <JSwede!51aaf86c@gateway/web/freenode/ip.> has joined #yocto18:15
*** armpit <armpit!~armpit@> has joined #yocto18:22
*** kanavin_home <kanavin_home!> has quit IRC18:22
*** mckoan is now known as mckoan|away18:23
*** xtron1 <xtron1!~xtron@> has joined #yocto18:24
JSwedeHi. I have created a custom layer, and created a bbappends file that points to a configuration fragment (at least according to my understanding). In my case the configuration fragment only contains one line: "CONFIG_TUN=y". Is there a way to check that the build successfully added this line to the kernel config without actually flashing the image to a real board (since I do not have the hardware where I currently am)?18:24
*** kanavin_home <kanavin_home!> has joined #yocto18:25
*** cquast <cquast!~cquast@> has quit IRC18:28
*** apteryx <apteryx!~maxim@> has quit IRC18:29
aehs29JSwede: what do you mean by "points to"18:31
yatesin general, if a recipe DEPENDS on a library, will the link (ld) command for the recipe need to specify a special path to the library via a -L<libpath> option?18:31
aehs29JSwede: easiest way would probably be to check the kernel build directory and open the .config, if the config is there, then youre golden18:31
aehs29JSwede: just fyi if its not there it does not necessarily mean that your bbappend isnt "pointing" to it correctly, there could be dependency issues or something18:32
*** georgem <georgem!~georgem@> has quit IRC18:32
*** georgem <georgem!~georgem@> has joined #yocto18:33
aehs29yates: the linker should be able to pick them up automatically18:33
yatesJSwede: what aehs29 said. so that your files are kept after building, it may be helpful to use devtool18:33
*** dv_ <dv_!~dv@> has quit IRC18:33
yatesaehs29: ok, well it's not! :(18:34
yatesi think i know why though18:35
aehs29yates: ideally, it should18:35
yatesi'm specifying a -sysroot in my link command18:35
aehs29yates: well that would change where the linker is looking for it, the -sysroot parameter should also be populated automaticlaly18:36
JSwedeaehs29: If I look in workspace/<project>/tmp/work/<abi dir>/<kernel>/<version>/ the config file is there and it contains CONFIG_TUN=y just as it should. Then I guess I'm all set :) Thanks!18:36
aehs29JSwede: I think youre still missing a directory "linux-build-something", the .config file should be in there18:37
aehs29JSwede: just make sure youre looking at the final .config18:37
*** labelette14 <labelette14!~labelette@> has joined #yocto18:38
JSwedeaehs29: ... Ah, maybe I misunderstood. I am not looking at a complete .config file. And now the server was shut down  for me so I can't check anything else today. I will give it another shot tomorrow.18:38
aehs29yates: addind --verbose to the ld command should help you figuring out where its looking for the libraries18:39
aehs29JSwede: sure, but yes, it should be a complete .config18:40
JSwedeaehs29: thanks, then I won't have to sit idle tomorrow :)18:41
*** JSwede <JSwede!51aaf86c@gateway/web/freenode/ip.> has quit IRC18:42
*** dv_ <dv_!> has joined #yocto18:48
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC18:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:57
*** ant_home <ant_home!> has joined #yocto19:00
*** armpit <armpit!~armpit@> has quit IRC19:08
*** yann <yann!> has quit IRC19:10
yateswhen does yocto build the cross-toolchain? does it happen automatically when the first recipe is built?19:10
yatesyates: yes19:18
yatesok, and where does that toolchain reside?19:19
aehs29yates: yes, the native and cross toolchain tasks are executed by the runqueue before due to their dependencies, and they reside in the sysroot19:20
yatesfrom the overivew and concepts manual, section 2.7: During a build process, the build system tracks dependencies and performs a native or cross-compilation of the package. As a first step in a cross-build setup, the framework attempts to create a cross-compiler toolchain (i.e. Extensible SDK) suited for the target platform.19:20
yatesaehs29: ok, thanks19:20
*** toanju <toanju!> has joined #yocto19:26
yatesaehs29: is the proper sysroot specified via the environment variable SYSROOT?19:28
yatesi'm using my own custom makefiles and am getitng wrapped around the axle a bit here19:29
kergothyates: 'first recipe' isn't relevant, it's all based on dependencies. base.bbclass specifies the defualt deps on the cross toolchain via BASEDEPENDS, unless opted out with INHIBIT_DEFAULT_DEPS or inheriting a class that does the same, like native19:31
*** gtristan <gtristan!~tristanva@> has joined #yocto19:41
*** xtron1 <xtron1!~xtron@> has quit IRC19:46
aehs29yates: I think thats probably why you're having issues with the --sysroot parameter to gcc, the Makefile needs to use what it gets from the build system, you can look at the variables such as CC , CFLAGS or LDFLAGS if you open the run.do_compile script inside the temp directory which is inside the work directory for your recipe, if you look at CC for example it already should have a --sysroot parameter19:47
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:48
robbawebbakhem: Thanks for your suggestion about hostame for determining MACHINE at image runtime! One more robust solution that I could think of is to create a recipe that adds the value of MACHINE to a file in the rootfs, such as /etc/machine/20:01
khemI think /etc/os-release might be for it20:02
*** dreyna <dreyna!> has quit IRC20:15
*** berton <berton!~berton@> has quit IRC20:17
*** yann <yann!> has joined #yocto20:30
yatesrburton: i see in the wx-config script where your binconfig_package_preprocess() performed this substitution: -e 's:${STAGING_LIBDIR}:${libdir}:g;'20:35
yatesthis was the <libpath> on a line in wx-config that issued a -L<libpath>  when generating library configuration info20:36
yatesnm. i thought it was creating an error there, but i think not.20:37
yateswell, let me continue..20:38
yateswith that -L${libdir}, a subsequent recipe build that DEPENDS on wxwidgets errors out at the link stage: | /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find /lib/
kergoth-L${libdir} in a target recipe is going to lead to pain, as that'll reference files on the host. it's also just plain redundant, as that's in the default search path20:40
kergothjust drop it entirely20:40
yateskergoth: already tried that20:40
kergothand this sort of thing is precisely the type of pain rburton warned you you'd run into trying to use a -config script, and is why binconfig.bbclass exists20:40
yateswell i have to deal with it someway.20:41
yatesif i remove the -L, several the libraries wxwidgets DEPENDS on are not found20:41
yatesspeaking of just the compiler/linker operation, shouldn't a "-L" _append_ the path to the existing search paths/20:43
yatesanother unrelated recipe i wrote also issues a -lpthread and it gets resolved just fine. works.20:44
yatesso the sdk has the pthread library, why isn't it finding it with a -L?20:45
yatesif the -lpthread occurs AFTER the -L<libpath>, does that limit the compiler to search for it JUST IN THAT <libpath>?20:46
yatesthat's what it's acting like.20:46
yateskergoth: i am using the binconfig.bbclass. i'm not sure if you were intimating i disabled it.20:47
kergothno, it doesn't, but pthread is special. /usr/lib/, iirc, is generally a linker script20:48
kergothif it loads the host one, it'll go directly to /lib rather than a path relative to the location of the .so20:48
yateskergoth: i don't understand your point. special or not, if one of my recipes with a -lpthread works, why wouldn't this one?20:53
kergothI just told you, if /usr/lib is in the search path, it'll grab the .so from there first and break20:53
kergothit doesn't limit to only that path, but the result is the same, as it grabs the first one it finds20:53
kergothyou can't include host paths in the library esarch path when crosscompiling20:54
yateswhy would /usr/lib be in the search path?20:54
kergothi don't understand the question.20:55
kergothlibdir by definition is the path in the target rootfs where the libs get installed. in non-native recipes, that's ${prefix}/lib, aka /usr/lib20:56
* kergoth shrugs, gets back to work20:56
yateskergoth: you said "if /usr/lib is in the search path". so i asked why would that happen? in a cross build, you should be using another sysroot, right?20:57
yatesmore specifically, why would the search path in one of my recipes NOT contain /usr/lib, yet another recipe DOES contain /usr/lib. when the recipes are structured the same with the exception of this -L?20:58
kergothno, —sysroot affects default paths only, you can specify -I/-L paths to be relative to sysroot by prefixing with =, otherise they're interpreted as absolute paths, not paths relative to the sysroot.20:58
kergothsee also
kergothafaik, anyway20:58
yatesok, let me check that.20:59
yatesboth recipes contain a -lpthread20:59
kergoth-L/usr/lib is referencing a host path, not a path relative to the sysroot, and the host's hasn't been fixed up the way ours has21:00
yatesbut that's not where my -L is pointing: -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib21:01
kergoththat's the most likely cause, anyway, as far as I can tell. could be missing something, but i'd eliminate that before digging elsewhere21:01
kergoththen something has adjusted it back to STAGING_LIBDIR, don't see a problem with that, but if ithat's the case i'd check the actual it's linking against to ensure it's sane21:02
yatesgood idea21:03
kergothif it's trying to link to /lib/libpthread, it's probably a hosted linker script unless something else is going on. could add -v to the linker commandline perhaps?21:04
kergothand just cat the libpthread.so21:04
yatesgood ideas, thanks. i will.21:05
kergothnp, good luck with it, sounds like it's an awfully painful recipe21:10
yatesyou can say that again. thanks!21:11
*** Crofton|work <Crofton|work!> has quit IRC21:28
yatesi can see a little further what's happening: there is a script at -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib21:31
yatesit's apparently the two paths specified in that GROUP that are causing the error21:31
*** tprrt <tprrt!> has joined #yocto21:36
*** JaMa <JaMa!~martin@> has quit IRC21:39
*** meow` <meow`!> has joined #yocto21:43
*** gtristan <gtristan!~tristanva@> has quit IRC21:48
*** guillaumekh <guillaumekh!5a5674df@gateway/web/freenode/ip.> has quit IRC21:49
*** Crofton|work <Crofton|work!~Crofton@> has joined #yocto21:58
*** toanju <toanju!> has quit IRC22:01
*** WillMiles <WillMiles!> has quit IRC22:22
*** rburton <rburton!> has quit IRC22:23
robbawebbakhem: Ahh i see! So I'll probably bbappend the os-release recipe to add MACHINE. Do you think this would be an addition that22:35
robbawebbaDo you think that this would be an addition worth submitting a patch for?22:36
*** marka <marka!~masselst@> has quit IRC22:37
khemI am not sure22:43
*** kristoiv <kristoiv!> has joined #yocto22:48
aehs29robbawebba: I think the image-buildinfo class does something similar22:51
aehs29just saying thats another option22:51
*** apteryx <apteryx!~maxim@> has joined #yocto22:55
*** comptroller <comptroller!> has quit IRC23:22
*** no_such_user <no_such_user!> has quit IRC23:27
robbawebbaaehs29: ahh, nice suggestion. I'll take a look at both.23:30
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC23:32
*** ant_home <ant_home!> has quit IRC23:32
*** kristoiv <kristoiv!> has quit IRC23:33
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto23:34
*** comptroller <comptroller!> has joined #yocto23:35

Generated by 2.11.0 by Marius Gedminas - find it at!