*** florian_kc <florian_kc!~florian@dynamic-093-131-127-068.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds) | 00:06 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 00:31 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 00:31 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 00:39 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 00:43 | |
*** davidinux <davidinux!~davidinux@host-82-53-212-205.retail.telecomitalia.it> has quit IRC (Ping timeout: 268 seconds) | 01:04 | |
*** davidinux <davidinux!~davidinux@host-79-54-161-160.retail.telecomitalia.it> has joined #yocto | 01:12 | |
*** rber|res <rber|res!~rber|res@62-46-89-217.adsl.highway.telekom.at> has joined #yocto | 01:32 | |
*** RobertBerger <RobertBerger!~rber|res@62-46-89-217.adsl.highway.telekom.at> has quit IRC (Ping timeout: 248 seconds) | 01:34 | |
*** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 01:39 | |
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Ping timeout: 265 seconds) | 01:43 | |
*** chep` is now known as chep | 01:43 | |
*** starblue <starblue!~juergen@dslb-188-100-142-236.188.100.pools.vodafone-ip.de> has quit IRC (Ping timeout: 250 seconds) | 01:45 | |
*** starblue <starblue!~juergen@dslb-094-220-106-043.094.220.pools.vodafone-ip.de> has joined #yocto | 01:47 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 01:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 01:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 265 seconds) | 01:54 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 01:54 | |
*** abdullahie[m] <abdullahie[m]!~abdullahi@2001:470:69fc:105::2:8af7> has joined #yocto | 02:02 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:27 | |
*** abdullahie[m] <abdullahie[m]!~abdullahi@2001:470:69fc:105::2:8af7> has quit IRC (K-Lined) | 02:44 | |
*** KurtKiefer[m] <KurtKiefer[m]!~kekieferm@2001:470:69fc:105::2:61a8> has joined #yocto | 03:14 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 265 seconds) | 03:24 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 03:24 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 260 seconds) | 03:29 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 03:29 | |
*** cmpdude <cmpdude!~cmpdude@14-201-56-110.static.tpgi.com.au> has joined #yocto | 03:45 | |
cmpdude | hi all - anyone know how to persuade the linux-stable recipe to build the tools in /tools/iio? | 03:53 |
---|---|---|
*** cmd <cmd!~cmd@user/cmd> has quit IRC (Ping timeout: 252 seconds) | 04:06 | |
rabbi[11] | fabatera[m]: thanks a ton forr all the steps. | 04:09 |
*** amitk <amitk!~amit@103.208.69.37> has joined #yocto | 04:11 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:32 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 265 seconds) | 04:49 | |
*** mrnuke_ <mrnuke_!~mrnuke@c-98-197-58-203.hsd1.tx.comcast.net> has quit IRC (Ping timeout: 265 seconds) | 04:50 | |
*** rabbi[11] <rabbi[11]!~rabbi11]@205.251.233.52> has quit IRC (Ping timeout: 252 seconds) | 04:50 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 04:54 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 04:59 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 05:48 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:48 | |
*** Ram-Z <Ram-Z!~Ram-Z@li1814-254.members.linode.com> has quit IRC (Ping timeout: 246 seconds) | 05:50 | |
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:00 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:03 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:04 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:09 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 244 seconds) | 06:09 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 06:09 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 260 seconds) | 06:14 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:14 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 06:14 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:14 | |
*** vmeson <vmeson!~rmacleod@23-233-86-175.cpe.pppoe.ca> has quit IRC (Ping timeout: 264 seconds) | 06:15 | |
*** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:d4cc:dbff:fe3c:3b93> has quit IRC () | 06:33 | |
*** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:d4cc:dbff:fe3c:3b93> has joined #yocto | 06:37 | |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 06:44 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:44 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:44 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:45 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 06:46 | |
*** mckoan|away is now known as mckoan | 06:47 | |
mckoan | good morning | 06:47 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 06:52 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 250 seconds) | 06:57 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:59 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:00 | |
*** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:d4cc:dbff:fe3c:3b93> has quit IRC () | 07:02 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 07:03 | |
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Quit: vladest) | 07:04 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 250 seconds) | 07:04 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 07:04 | |
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:10d6:cd9b:247:1e52> has joined #yocto | 07:05 | |
*** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:d4cc:dbff:fe3c:3b93> has joined #yocto | 07:06 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 07:06 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 265 seconds) | 07:09 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 07:09 | |
*** Ram-Z <Ram-Z!~Ram-Z@li1814-254.members.linode.com> has joined #yocto | 07:12 | |
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 07:15 | |
tomzy_0 | Hi | 07:16 |
tomzy_0 | I got a question, little bit related with Yocto, maybe someone would be able to help me. In one of projects I needed to make big update from Warrior to Kirkstone version - after that one of custom apps written in golang is unable to compile. CGO is used there and compilation fails on problems with linker. This is what I get | 07:18 |
tomzy_0 | | arm-project-linux-gnueabi-gcc: warning: "--sysroot=/build/tmp/work/cortexa7t2hf-neon-vfpv4-project-linux-gnueabi/go-app/0.0.2-r0/recipe-sysroot": linker input file unused because linking not done | 07:18 |
tomzy_0 | | arm-project-linux-gnueabi-gcc: error: "--sysroot=/build/tmp/work/cortexa7t2hf-neon-vfpv4-project-linux-gnueabi/go-app/0.0.2-r0/recipe-sysroot": linker input file not found: No such file or directory | 07:18 |
tomzy_0 | I tried to reproduce this error in different environment, take Ubuntu 22.04 with gcc v11 (same as in Yocto) and could compile without problems | 07:19 |
tomzy_0 | So are there some default flags that are being added to the cross compiler which causes the linker to fail? | 07:20 |
*** NP9 <NP9!~NP9@smtp2.nedap.com> has joined #yocto | 07:20 | |
*** Maxxed52 <Maxxed52!~Maxxed@nrgt.net> has quit IRC (Quit: Ping timeout (120 seconds)) | 07:20 | |
*** Maxxed52 <Maxxed52!~Maxxed@nrgt.net> has joined #yocto | 07:21 | |
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has joined #yocto | 07:26 | |
*** cmpdude <cmpdude!~cmpdude@14-201-56-110.static.tpgi.com.au> has quit IRC (Ping timeout: 252 seconds) | 07:37 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 07:40 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:40 | |
*** rber|res <rber|res!~rber|res@62-46-89-217.adsl.highway.telekom.at> has quit IRC (Ping timeout: 265 seconds) | 07:41 | |
*** manuel1985 <manuel1985!~manuel198@185.144.162.58> has joined #yocto | 07:44 | |
*** zpfvo1 <zpfvo1!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 07:45 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:47 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 252 seconds) | 07:47 | |
*** rber|res <rber|res!~rber|res@62-46-95-134.adsl.highway.telekom.at> has joined #yocto | 07:51 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6511:2900:2ce:39ff:fecf:efcd> has joined #yocto | 07:51 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6511:2900:2ce:39ff:fecf:efcd> has quit IRC (Client Quit) | 07:51 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6511:2900:2ce:39ff:fecf:efcd> has joined #yocto | 07:53 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:05 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:19 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 08:40 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:40 | |
*** zpfvo1 <zpfvo1!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 250 seconds) | 08:47 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 08:48 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 08:48 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 264 seconds) | 08:53 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 08:53 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 09:02 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 09:10 | |
*** manuel1985 <manuel1985!~manuel198@185.144.162.58> has quit IRC (Remote host closed the connection) | 09:17 | |
*** fuzzybear396544 <fuzzybear396544!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 09:27 | |
fuzzybear396544 | I'm using bitbake -c unpack <recipe> and I want to view the result of this operation. | 09:27 |
fuzzybear396544 | How can I have the operations printed to STDOUT so I can see in which directory the unpacked files exist? | 09:27 |
fuzzybear396544 | Alternatively, how can I print the script that's running for do_unpack | 09:28 |
fuzzybear396544 | Based on inspection it looks like they're landing in ./tmp/work/core2-64-poky-linux/<recipe> but there a few subdirectories there that I'm not sure are related to do_unpack and there may be higher-level directories where things are being written which I don't see. | 09:29 |
NP9 | look for the temp subfolder, there should be a log.do_unpack which should contain the output of that task | 09:34 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 09:35 | |
fuzzybear396544 | Oh, yeah, I found that! Thanks! | 09:36 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:36 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 09:36 | |
fuzzybear396544 | NP9 What's the difference between <recipe>/image and <recipe>/package ? | 09:36 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:36 | |
qschulz | fuzzybear396544: the sources are unpacked by default in S | 09:41 |
qschulz | fuzzybear396544: except for the file:// ones in SRC_URI, where it's put into WORKDIR IIRC | 09:42 |
qschulz | so you can find the path with bitbake-getvar tool or bitbake -e <recipe> | 09:42 |
NP9 | I would expect the /image to be used when building the image and /package when building a package with the recipe, however that's an assumption that I'm not totally sure about | 09:46 |
fuzzybear396544 | qschulz You're right about file:// ones, apparently. | 09:46 |
fuzzybear396544 | NP9 It's weird because bitbake <recipe> populates both package/ and image/ with my do_install dummy outptu | 09:46 |
fuzzybear396544 | s/outptu/output | 09:46 |
fuzzybear396544 | qschulz bitbake-getvar seems like a great tool! Let me read the docs! | 09:47 |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 268 seconds) | 09:48 | |
fuzzybear396544 | qschulz bitbake-getvar -r <recipe> S worked great! Thanks a lot! | 09:48 |
qschulz | fuzzybear396544: https://docs.yoctoproject.org/overview-manual/concepts.html#configuration-compilation-and-staging and https://docs.yoctoproject.org/overview-manual/concepts.html#package-splitting | 09:49 |
qschulz | I do not know why we need the package directory over the image directory though | 09:49 |
fuzzybear396544 | qschulz Thanks for the links. What do you mean "why we need X directory over Y directory"? | 09:50 |
fuzzybear396544 | Do you mean "over" like "in favor of" or "over" like "in addition to" or over like "parent directory"? | 09:50 |
qschulz | fuzzybear396544: in addition to | 09:51 |
fuzzybear396544 | Oh, okay. | 09:51 |
rburton | NP9: yeah you're wrong :) | 09:52 |
fuzzybear396544 | I guess because packages can be generated separately from images and the requirements for each may be different. | 09:52 |
*** manuel1985 <manuel1985!~manuel198@185.144.162.58> has joined #yocto | 09:56 | |
NP9 | rburton looking at the links do_install uses /image and do_package uses /package before breaking it up in different packages | 09:57 |
RP | rburton: one CVE now. Can you guess which recipe? | 09:58 |
rburton | haha | 09:58 |
*** starblue <starblue!~juergen@dslb-094-220-106-043.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds) | 09:58 | |
rburton | NP9: correct | 09:58 |
*** starblue <starblue!~juergen@dslb-094-220-106-043.094.220.pools.vodafone-ip.de> has joined #yocto | 10:00 | |
NP9 | rburton thanks, any insights as to why do_package needs its own dir and not just reuse /image? | 10:01 |
fabatera[m] | This recipe fails to fetch in Honister, but works in hardknott and older:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/7a186dc3469f7bbc2b792f85f45301f14ee819c1>) | 10:01 |
*** zpfvo <zpfvo!~fvo@i59f5cdb4.versanet.de> has joined #yocto | 10:01 | |
rburton | NP9: because do_package does work to the tree, so it has to copy | 10:01 |
NP9 | ye that makes sense (y) | 10:03 |
fabatera[m] | This recipe fails to fetch in Honister, but works in hardknott and older:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/4782ace297603393afc08388a90e879dd93c8cbf>) | 10:03 |
*** fuzzybear396544 <fuzzybear396544!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 10:05 | |
tomzy_0 | Hi, I got a question, little bit related with Yocto, maybe someone would be able to help me. In one of projects I needed to make big update from Warrior to Kirkstone version - after that one of custom apps written in golang is unable to compile. CGO is used there and compilation fails on problems with linker. This is what I get | 10:06 |
tomzy_0 | | arm-project-linux-gnueabi-gcc: warning: "--sysroot=/build/tmp/work/cortexa7t2hf-neon-vfpv4-project-linux-gnueabi/go-app/0.0.2-r0/recipe-sysroot": linker input file unused because linking not done | 10:07 |
tomzy_0 | | arm-project-linux-gnueabi-gcc: error: "--sysroot=/build/tmp/work/cortexa7t2hf-neon-vfpv4-project-linux-gnueabi/go-app/0.0.2-r0/recipe-sysroot": linker input file not found: No such file or directory | 10:07 |
tomzy_0 | I tried to reproduce this error in different environment, take Ubuntu 22.04 with gcc v11 (same as in Yocto) and could compile without problems | 10:07 |
tomzy_0 | So are there some default flags that are being added to the cross compiler which causes the linker to fail? | 10:07 |
*** fuzzybear39653 <fuzzybear39653!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 10:08 | |
fuzzybear39653 | I have a do_unpack_prepend but it looks like it needs to be a python function. How can I write shell scripts in do_unpack_prepend? | 10:09 |
rburton | tomzy_0: you _need_ the sysroot to be passed to gcc, so i'd blame the makefile | 10:09 |
rburton | fuzzybear39653: do_unpack[prefunc] | 10:09 |
fuzzybear39653 | :pray: | 10:09 |
rburton | prepend and append *literally* add code to the existing code. do_unpack is python, so you need to write _very careful_ python. prefuncs are better if you just want to do something non-trivial. | 10:09 |
rburton | (look in the docs how to use them) | 10:10 |
fuzzybear39653 | rburton [postfunc] for _append? | 10:10 |
fuzzybear39653 | Right now I have bb.build.exec_func('foo_shell_func', d) in my _prepend . | 10:10 |
tomzy_0 | rburton I thought that too, but the sysroot is set inside recipe by adding the following | 10:10 |
tomzy_0 | CGO_CFLAGS=\"--sysroot=${RECIPE_SYSROOT}\" \ | 10:10 |
tomzy_0 | CGO_LDFLAGS=\"--sysroot=${RECIPE_SYSROOT}\" \ | 10:10 |
tomzy_0 | What's annoying is that I do not even know, with which files linker has a problem | 10:11 |
*** fuzzybear39653 <fuzzybear39653!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 10:17 | |
*** fuzzybear396522 <fuzzybear396522!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 10:20 | |
fuzzybear396522 | I have a recipe for which I need to obtain the version number of another recipe. | 10:21 |
fuzzybear396522 | Is there a way to accomplish this? | 10:21 |
rburton | no | 10:21 |
fuzzybear396522 | I have to hard-code the value? | 10:22 |
rburton | you could write the versions to the rootfs and fetch them at runtime | 10:30 |
rburton | what happens if you upgrade the other recipe: is the first recipe definitely going to rebuild? | 10:30 |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 250 seconds) | 10:36 | |
fuzzybear396522 | rburton We _could_ share a file that has the version info. The context is that we have a tarball which contains a tarball. The inner tarball is a dependency of the outer tarball. | 10:37 |
fuzzybear396522 | So, when we build the inner tarball we need the path to the outer tarball in order to extract the inner one (the outer tarball's name contains the version number of the dependent package) | 10:37 |
fuzzybear396522 | So, if we upgrade the dependent package (outer tarball) then the first one may/may not be rebuilt. But, the path to the inner tarball should be the same (even if the inner tarball name does change, the path to find the inner tarball should be the same). | 10:39 |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 10:39 | |
fuzzybear396522 | I'm having a problem building a package because a build step requires the execution of a binary which isn't for the architecture of the build machine. | 10:39 |
fuzzybear396522 | So, the build fails. | 10:39 |
fuzzybear396522 | That is, one of the build products is a binary used to compete the build. | 10:39 |
fuzzybear396522 | Butt, that binary can't be executed. | 10:39 |
fuzzybear396522 | Using `file` it actually looks like the right architecture but it looks dynamically-linked, so my shared library paths (on the build machine) aren't the same as the bitbake sysroot/build environment. | 10:40 |
fuzzybear396522 | What do people normally do in this case? | 10:40 |
fuzzybear396522 | s/looks dynamically, linked, so my shared library paths/looks dynamically linked, and I guess that my shared library paths/ | 10:41 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:41 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:41 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 10:42 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:42 | |
*** fuzzybear396522 <fuzzybear396522!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 10:59 | |
*** fuzzybear396527 <fuzzybear396527!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 11:02 | |
*** manuel1985 <manuel1985!~manuel198@185.144.162.58> has quit IRC (Ping timeout: 265 seconds) | 11:05 | |
*** ptsneves <ptsneves!~Thunderbi@031011128148.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 11:06 | |
*** BobPungartnik <BobPungartnik!~Pung@177.41.202.109> has joined #yocto | 11:07 | |
rburton | fuzzybear396527: makefile problem, it's perfectly possible to build native to run. the makefile needs to respect BUILD_CC BUILD_CFLAGS BUILD_LDFLAGS etc. | 11:07 |
*** BobPungartnik <BobPungartnik!~Pung@177.41.202.109> has quit IRC (Client Quit) | 11:08 | |
*** fuzzybear396527 <fuzzybear396527!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 11:12 | |
*** dallas_bruno[m] <dallas_bruno[m]!~dallasbru@2001:470:69fc:105::2:8c0d> has joined #yocto | 11:12 | |
*** Ram-Z <Ram-Z!~Ram-Z@li1814-254.members.linode.com> has quit IRC (Quit: ZNC - http://znc.in) | 11:18 | |
*** Ram-Z <Ram-Z!~Ram-Z@li1814-254.members.linode.com> has joined #yocto | 11:21 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:22 | |
*** fuzzybear396545 <fuzzybear396545!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 11:22 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:22 | |
fuzzybear396545 | rburton okay, deal. It must be the Makefile not respecting those Makefile env vars. Because, outside of Yocto in the shell it works just fine. | 11:23 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:32 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:33 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 250 seconds) | 11:33 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 11:33 | |
*** cmd <cmd!~cmd@user/cmd> has joined #yocto | 11:35 | |
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has joined #yocto | 11:36 | |
*** zpfvo <zpfvo!~fvo@i59f5cdb4.versanet.de> has quit IRC (Ping timeout: 252 seconds) | 11:36 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 268 seconds) | 11:39 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 11:40 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 11:41 | |
rburton | there's no standard for those, which makes it fun | 11:42 |
rburton | autotools _tends_ to use CC_FOR_BUILD etc, but that's not a standard. if you've got a plain makefile, all bets are off. | 11:42 |
rburton | better advice given if you can point to the makefile | 11:42 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:43 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:43 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 11:44 | |
*** fuzzybear396545 <fuzzybear396545!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 11:50 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 11:53 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 11:59 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 11:59 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 12:03 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 12:04 | |
*** fuzzybear396541 <fuzzybear396541!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 12:08 | |
fuzzybear396541 | I have a DISTRO_FEATURES="foo" and in a <recipe>.bbappend I have DEPENDS:append:foo = <dependency> | 12:09 |
fuzzybear396541 | But, when I bitbake -g <recipe> I don't see <dependency> in the output. | 12:09 |
fuzzybear396541 | I tried putting DEPENDS:append:foo in <recipe>.bb. I also tried DEPENDS_append_df-foo = <dependency> . | 12:10 |
fuzzybear396541 | None of those worked. | 12:10 |
fuzzybear396541 | How should I specify that <recipe>.bb depends on <dependency> when DISTRO_FEATURES="foo" is present. | 12:11 |
rburton | check distro features is set to what you expect | 12:11 |
rburton | but distro features are not overrides | 12:11 |
rburton | so :foo won't work | 12:12 |
fuzzybear396541 | It's a space-separated list in conf/local.conf that has DISTRO_FEATURES="foo qux quz" | 12:12 |
rburton | see eg classes-recipe/update-rc.d.bbclass:DEPENDS:append:class-target = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', ' update-rc.d initscripts', '', d)}" | 12:12 |
rburton | you won't need the class-target bit | 12:12 |
fuzzybear396541 | qschulz recommended this syntax yesterday. | 12:12 |
fuzzybear396541 | rburton Okay, so.I need to execute bb.utls.contains | 12:13 |
fuzzybear396541 | Is this better in <recipe>.bb or <recipe>.bbappend ? | 12:14 |
fuzzybear396541 | Seems like it could go in either place. | 12:14 |
rburton | if you own the recipe, there's no need to write a bbappend | 12:14 |
fuzzybear396541 | I own it, yeah. | 12:14 |
fuzzybear396541 | Okay. Thanks. | 12:14 |
fuzzybear396541 | rburton I see my <dependency> in the output of bitbake -g <recipe> now after adding DEPENDS:append = "${@bb.utils.contains('DISTRO_FEATURES', '<my-distro-feature>', '<dependency>', '', d)}" | 12:19 |
fuzzybear396541 | Thanks a lot! | 12:19 |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 252 seconds) | 12:27 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 12:30 | |
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Ping timeout: 252 seconds) | 12:33 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:33 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:33 | |
*** fuzzybear396541 <fuzzybear396541!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 12:52 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 12:55 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 13:06 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 268 seconds) | 13:06 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 13:07 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 13:10 | |
*** NP9 <NP9!~NP9@smtp2.nedap.com> has quit IRC (Ping timeout: 252 seconds) | 13:29 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 13:30 | |
*** kscherer <kscherer!~kscherer@dsl-173-206-238-19.tor.primus.ca> has joined #yocto | 13:39 | |
*** amitk <amitk!~amit@103.208.69.37> has quit IRC (Ping timeout: 246 seconds) | 13:43 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 13:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 13:49 | |
*** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Read error: Connection reset by peer) | 13:49 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:53 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 248 seconds) | 13:54 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 13:54 | |
*** mrnuke <mrnuke!~mrnuke@c-98-197-58-203.hsd1.tx.comcast.net> has joined #yocto | 13:59 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 14:00 | |
*** grma <grma!~gruberm@80.93.38.128> has quit IRC (Ping timeout: 252 seconds) | 14:01 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 244 seconds) | 14:01 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:07 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 14:08 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 268 seconds) | 14:09 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 14:11 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 14:18 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 14:19 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 250 seconds) | 14:20 | |
*** fuzzybear396531 <fuzzybear396531!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 14:20 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 14:22 | |
rfuentess | question. bb.utils.contains_any how reliable is for checking settings from the image recipe in other packages recipes ? | 14:26 |
rfuentess | I'm a little confused due the lifetime of the environment variables | 14:26 |
rburton | recipes are isolated from each other | 14:27 |
rburton | there's no concept of variables being set in a recipe and then being used in an image | 14:27 |
rburton | an image is a recipe, and recipes are isolated | 14:27 |
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto | 14:28 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 14:28 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 268 seconds) | 14:32 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:32 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 265 seconds) | 14:37 | |
rfuentess | yeah. that is what I learned in the hard way, but then I was requested to evaluate that tool. | 14:40 |
JPEW | denix, Crofton: I've just release Pyrex 1.7.0 which adds Ubuntu 22.04 and Yocto 4.0 compatibility | 14:42 |
Crofton | JPEW: thanks | 14:44 |
*** dev1990 <dev1990!~dev@178-36-249-43.adsl.inetia.pl> has quit IRC (Quit: Konversation terminated!) | 14:49 | |
*** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 14:52 | |
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 265 seconds) | 14:52 | |
*** Guest66 <Guest66!~Guest66@mail.digitalendoscopy.de> has joined #yocto | 14:52 | |
*** Guest66 <Guest66!~Guest66@mail.digitalendoscopy.de> has quit IRC (Client Quit) | 14:53 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 14:53 | |
*** mckoan is now known as mckoan|away | 14:53 | |
fabatera[m] | My python package inherits pypi | 15:03 |
fabatera[m] | In honister, SRC_URI is set by the recipe with the github url AND is is being prepended by pypi with a url/file.tar.gz | 15:03 |
fabatera[m] | Fetch is failing to get the tarball prepended and is not trying the github url (build error) | 15:03 |
fabatera[m] | Is it a yocto bug? | 15:03 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 265 seconds) | 15:04 | |
rburton | fabatera[m]: don't set the SRC_URI in the recipe if you want to fetch from pypi. if you don't want to fetch from pypi, don't inherit pypi | 15:06 |
fabatera[m] | Alright, thanks! I got that now. So this is the new way and is not allowed anymore (as it was working fine until hardknott). | 15:10 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 15:22 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 265 seconds) | 15:22 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 15:24 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 246 seconds) | 15:27 | |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto | 15:29 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:30 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 246 seconds) | 15:32 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 15:35 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-068-030.2.244.pool.telefonica.de> has joined #yocto | 15:45 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 15:49 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 15:49 | |
denix | JPEW: great! I'll be testing it today | 15:53 |
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 268 seconds) | 16:07 | |
fuzzybear396531 | It looks like that during the compile phase that the dynamic linker (in recipe-sysroot) is actually resolving to the build machine's libc which is causing a build-time failure since I need to run dynamically-linked executables during the compile phase. | 16:22 |
fray | what is the symptom? The most common faults are using the wrong compiler, not passing the CFLAGS (or LDFLAGS), and programs hard coding them | 16:23 |
rburton | fuzzybear396531: lots of recipes do this, so i still blame the makefile | 16:23 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:24 | |
fray | (i.e. hard coding -L/usr/lib for instance WILL cause issues..) | 16:24 |
fuzzybear396531 | fray the symptom is that the executable can't run during the compile phase (ENOENT). Digging in it I discovered that it's a dynamic linker problem. | 16:24 |
rburton | fuzzybear396531: for example if you're using recipe-sysroot during a native build then it's doing something very wrong | 16:24 |
fuzzybear396531 | build-shared3% ../../recipe-sysroot/lib/ld-2.31.so --list ./$BINARY_THAT_NEEDS_TO_RUN | 16:24 |
fuzzybear396531 | linux-vdso.so.1 (0x00007ffe635ef000) | 16:24 |
fuzzybear396531 | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5815311000) | 16:24 |
fuzzybear396531 | /lib/ld-linux-x86-64.so.2 => ../../recipe-sysroot/lib/ld-2.31.so (0x00007f5815500000) | 16:24 |
fuzzybear396531 | fray No, hard coding -L into /usr/lib | 16:25 |
fuzzybear396531 | Not doing that. | 16:25 |
rburton | can you point us at a git repo? | 16:25 |
fuzzybear396531 | rburton no :( . It's corporate work. | 16:25 |
fray | if you are running that on the BUILD machine, you won't get reasonable results. There is a cross-ldd that was part of the cross-prelinker (I don't know if it still exists..) running it on the target is the only way to know what is ACTUALLY being done.. | 16:26 |
rburton | well, don't ask the target loader about the linkage, because that's not the loader that will be used | 16:26 |
fray | also checking your binary w/ objdump can help you identify if it has RPATHS or hard coded library paths in it (that migth point to /lib) | 16:26 |
fuzzybear396531 | I guess I'm confused about what sysroot-native is for. Isn't that the folder that contains all tools needed for the build? | 16:26 |
fray | sysroot-native is programs that run on the host, compiled for the host, USUALLY to assist in cross compilng.. | 16:27 |
fray | sysroot is target binaries | 16:27 |
fuzzybear396531 | fray I'm running it on the build machine. I'm trying to build this package using bitbake for the same architecture as the machine it's running on. | 16:27 |
fray | sysroot-native expects a custom environment to run. w/o the environment it may try to run against host libraries | 16:27 |
rburton | fuzzybear396531: just do LD_TRACE_LOADED_OBJECTS1= ./binary-to-run | 16:27 |
fuzzybear396531 | fray Okay, then I think it makes sense to use it in this case. | 16:27 |
rburton | (in a devshell) | 16:27 |
fray | sysroot (even for the same arch as the host) should NEVER be run on the host and inspected this way, you _WILL_ get invalid results.. | 16:27 |
fray | you need to chroot into the directory and run it | 16:27 |
fuzzybear396531 | rburton What's a devshell? That command fails in a normal shall (file not found). | 16:28 |
fray | sysroot-native can just be 'executed', assuming your environment is setup.. _sysroot_ though, you MUST be running as a target.. it expects you are on the target, with '/' being well / | 16:29 |
fuzzybear396531 | fray If I chroot into sysroot-native then the WORKDIR is out of my directory tree. | 16:29 |
fray | sysroot_-native_ doesn't need chroot.. _sysroot_ does | 16:29 |
fuzzybear396531 | This binary needs to execute on the build machine as a part of the compilation phase. | 16:29 |
fuzzybear396531 | So, I think it makes sense to use the linker from sysroot-native. | 16:29 |
fray | ignore the architecture 'sysroot' is targeting.. always assume it's different | 16:29 |
fuzzybear396531 | For sure. No problem. | 16:29 |
fuzzybear396531 | Yeah, I'm not considering sysroot at all. I haven't looked at it. | 16:29 |
fray | the compiler, linker, etc is in sysroot-native (or usually is).. so that is correct.. arguments passed to them need to include rthe --sysroot=, and other arguments to make sure it's right | 16:30 |
fray | Ok, so what are you building.. a _HOST_ tool, or a _TARGET_ tool? | 16:30 |
fuzzybear396531 | I'm building a HOST tool. | 16:30 |
fuzzybear396531 | --sysroot is present and correct. | 16:30 |
fray | (note, even the sysroot-native items are built with a sysroot.. because the sysroot-native provides it's own version of libc and many libraries) | 16:30 |
fuzzybear396531 | Yeah, sysroot-native has the right libc. | 16:31 |
fuzzybear396531 | If I LD_PRELOAD that libc then the executable runs. | 16:31 |
fray | ok, so then you are down to compiler (need the YP native compiler) and the sysroot-native for your build(s) | 16:31 |
fuzzybear396531 | What's the YP native compiler? | 16:32 |
fray | this is where i was saying the environment matters.. I dont remember how this works offhand. But there are some things configured in the standard YP evnrionemtn. Within the devshell though it all should be configured properly. | 16:32 |
fuzzybear396531 | How can I access a dev shell? | 16:32 |
fray | the key thing is (objdump can show you) what ld.so is the sysroot-native picking up? | 16:32 |
fuzzybear396531 | Which options should I pass to objdump? | 16:33 |
fray | just walking through my own build: | 16:33 |
fray | tmp/work/versal_net_generic-xilinx-linux/petalinux-image-everything/1.0-r0/recipe-sysroot-native/bin | 16:33 |
fray | objdump -x cpio | 16:33 |
fray | Dynamic Section: NEEDED libc.so.6 RUNPATH $ORIGIN/../usr/lib:$ORIGIN/../lib | 16:34 |
fray | file cpio | 16:34 |
fray | cpio: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /scratch/mhatle/git/internal/master/build-external/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a5f880659d790150deac15247f26711a9f1686be, stripped | 16:34 |
fray | thats the stuff to look for.. basically in my case the ld.so that will be called in that deep path.. and the objdump shows it's using RUNPATH and ORIGIN | 16:34 |
fuzzybear396531 | Nah, it only has the root-level path. | 16:35 |
fuzzybear396531 | ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, | 16:35 |
fuzzybear396531 | objdump -x didn't print that path... Weird. | 16:36 |
fray | ok.. so if you get an interpreter of /lib/ld-linux then either the linker or compiler was wrong. | 16:36 |
fray | OR the ldflags were wrong.. | 16:36 |
fray | basically the binary is linked to the wrong ld.so (even if the other parts are right) that is controlled via the LDFLAGS, I think | 16:36 |
fuzzybear396531 | Okay, this is great to know. Thanks a lot. | 16:37 |
fuzzybear396531 | How can I enter a dev shell, though? | 16:37 |
fuzzybear396531 | That sounds really useful. | 16:37 |
fuzzybear396531 | Can I run do_compile from there? | 16:37 |
fray | looking at bitbake cpio-native -e, I see: | 16:38 |
fray | export BUILD_LDFLAGS="-L/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/usr/lib -L/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/lib -Wl,--enable-new-dtags | 16:38 |
fray | -Wl,-rpath-link,/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/lib | 16:38 |
rburton | fuzzybear396531: can you share the log.do_compile fragment which builds this binary you want to run on the build host? | 16:38 |
fray | -Wl,-rpath,/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,/scratch/mhatle/git/internal/master/build-external/tmp/work/x86_64-linux/cpio-native/2.13-r0/recipe-sysroot-native/lib -Wl,-O1 -Wl,--allow-shlib-undefined | 16:38 |
fray | -Wl,--dynamic-linker=/scratch/mhatle/git/internal/master/build-external/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2" | 16:38 |
fray | it's that last -Wl,--dynamic-linker that sets the values | 16:38 |
fuzzybear396531 | rburton for sure, but it's a little long. | 16:38 |
fray | so if LDFLAGS isn't being handled, you won't get the right link | 16:38 |
fuzzybear396531 | fray Thanks a lot! | 16:38 |
rburton | fuzzybear396531: just the lines that builds that tool should be fine | 16:38 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 16:38 | |
fray | (BUILD_LDFLAGS and LDFLAGS are identical, I just pasted the first one).. but when you use bitbake -e <your recipe> look for 'export LDFLAGS=' | 16:38 |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.114.26> has quit IRC (Ping timeout: 260 seconds) | 16:39 | |
fuzzybear396531 | For sure. Even that is a bit long, though. | 16:39 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:39 | |
fray | for devshell.. bitbake -c devshell <your recipe> | 16:39 |
fuzzybear396531 | fray I've been living in bitbake -e all day (but mostly looking at CFLAGS). This is really helpful. | 16:39 |
fuzzybear396531 | fray Thanks! | 16:39 |
fray | ya, the LDFLAGS setup the ld path, the 'rpath' and the dynamic linker (and a few other things).. at a minimum it looks like you re missing the dynamic linker, but to be missing that it really looks like your makefile is ignoring the LDFLAGS | 16:40 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 16:40 | |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto | 16:40 | |
fray | hopefully this can help unblock you | 16:40 |
fuzzybear396531 | rburton it branches based on the presence of HOST_CC versus CC so it looks a little funky: | 16:42 |
fuzzybear396531 | x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/johrineh/code/outer-yocto-build/poky/build/tmp/work/core2-64-poky-linux/$PN/$PV/recipe-sysroot -o ../$BINARY -I.. -I../.. -I../../include -D$STUFF -fPIC | 16:42 |
fuzzybear396531 | --D$MORE_STUFF -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -fno-strict-aliasing -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM | 16:42 |
fuzzybear396531 | -DECP_NISTZ256_ASM $BINARY.o; \ | 16:42 |
fuzzybear396531 | else \ | 16:42 |
fuzzybear396531 | -o ../$BINARY -I../../include -I../../crypto $BINARY.c ../../crypto/sha/sha1dgst.c ; \ | 16:42 |
fuzzybear396531 | fi | 16:42 |
fuzzybear396531 | fray I think it will. | 16:42 |
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Quit: Leaving.) | 16:42 | |
rburton | fuzzybear396531: that's using target flags not BUILD_ | 16:42 |
fuzzybear396531 | rburton I'm sorry. I don't understand. | 16:42 |
rburton | fuzzybear396531: if a binary needs to be built to be executed on the host, it needs to use BUILD_CC BUILD_LDFLAGS BUILD_CPPFLAGS BUILD_CFLAGS etc | 16:43 |
fray | The recipe will DEFAULT to 'target' style.. When you inherit 'native', it switching LDFLAGS (and CFLAGS) to use the "BUILD"/host versions | 16:43 |
rburton | that is definitely using LDFLAGS (as it passes --sysroot) | 16:43 |
fuzzybear396531 | Ohhhhh | 16:43 |
rburton | well, --sysroot implies CC not BUILD_CC | 16:43 |
rburton | i'm presuming this is a target recipe that needs to build a single binary to run on the host | 16:44 |
fray | rburton, ya I missed that.. you are right | 16:44 |
fuzzybear396531 | rburton Yeah, exactly. | 16:44 |
rburton | the makefile needs to be cross-aware and know how to use a different compiler for host binaries vs target binaries | 16:44 |
fuzzybear396531 | rburton Okay, so the best thing to do would be to swap CC for BUILD_CC, here? | 16:45 |
fuzzybear396531 | And LDFLAGS for BUILD_LDFLAGS, etc.? | 16:45 |
rburton | is this plain makefiles or autotools or what? | 16:45 |
fray | that swap happens on the YP side of things.. (or should) | 16:45 |
fuzzybear396531 | rburton It's a plain makefile. | 16:45 |
fray | the makefile should just use CC, CFLAGS, LDFLAGS, etc. (unless it's a cross compiler) | 16:45 |
fray | then it's up to the recipe logic to switch the value of 'CC" from the target version to the 'native' version | 16:46 |
rburton | the one rule that generates this binary should use CC_FOR_BUILD instead of CC. CC_FOR_BUILD can default to CC | 16:46 |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has quit IRC (Ping timeout: 268 seconds) | 16:46 | |
fray | (same w/ cflags and ldflags).. bitbake -e should be able to show you what the LDFLAGS is set to (compared to the BUILD_LDFLAGS) | 16:46 |
fuzzybear396531 | fray It does use CC, CFLAGS, LDFLAGS, etc. unless HOST_CC is present. | 16:46 |
fuzzybear396531 | That's how the target's Makefile logic is expressed. | 16:46 |
rburton | actually BUILD_CC is exported, so use that name and it just works | 16:47 |
fray | ok | 16:47 |
fuzzybear396531 | rburton Okay, I'll swap out the CC stuff for BUILD_CC stuff. | 16:47 |
rburton | there's a trick you can do with make | 16:47 |
fuzzybear396531 | rburton give me all the tricks! | 16:47 |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto | 16:48 | |
rburton | iirc, mybinary: CC=${BUILD_CC} | 16:49 |
rburton | where mybinary is the target for your binary | 16:49 |
rburton | repeat for CFLAGS etc | 16:49 |
fuzzybear396531 | On new lines or comma-separated? | 16:49 |
rburton | and provide a default BUILD_CC?=$CC | 16:49 |
fuzzybear396531 | That's pretty slick. | 16:49 |
rburton | https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html suggests multiple assignments | 16:50 |
rburton | you're just overriding the variables for a specific target | 16:50 |
fuzzybear396531 | Yeah, and it avoids overwriting all the logic below the target. | 16:50 |
rburton | especially as you've written a good makefile which doesn't have a %o:%.c rule, right? :) | 16:50 |
rburton | i'll also point out here that make is terrible, use something like meson: it's better and handles stuff like this transparently | 16:51 |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has quit IRC (Ping timeout: 248 seconds) | 16:53 | |
*** vmeson <vmeson!~rmacleod@23-233-86-175.cpe.pppoe.ca> has joined #yocto | 16:54 | |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto | 16:55 | |
fuzzybear396531 | Well, so I didn't write this Makefile. | 16:55 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:56 | |
fuzzybear396531 | But, even then I don't know if %o:%.c is good..... | 16:56 |
fuzzybear396531 | Meson handles using the "right" compilers and linkers for build/target machine transparently, you mean? | 16:56 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 16:56 | |
rburton | yes | 16:56 |
rburton | you just say native:true | 16:57 |
fuzzybear396531 | Oh, I see. | 16:58 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:58 | |
fuzzybear396531 | Yeah, if all that's needed is to change out a couple of variables to make this cross-compile successfully then I don't think there's enough incentive to switch to a different build system. | 16:58 |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has quit IRC (Ping timeout: 265 seconds) | 17:05 | |
*** PhoenixMage <PhoenixMage!~phoenix@206.83.114.26> has joined #yocto | 17:07 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 17:10 | |
*** ptsneves <ptsneves!~Thunderbi@031011128148.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 250 seconds) | 17:14 | |
*** amitk <amitk!~amit@103.208.69.37> has joined #yocto | 17:16 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:17 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 17:17 | |
*** Guest12 <Guest12!~Guest12@80.174.116.206.dyn.user.ono.com> has joined #yocto | 17:18 | |
*** Guest12 <Guest12!~Guest12@80.174.116.206.dyn.user.ono.com> has quit IRC (Client Quit) | 17:20 | |
*** fuzzybear396531 <fuzzybear396531!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Quit: Ping timeout (120 seconds)) | 17:32 | |
*** dallas_bruno[m] <dallas_bruno[m]!~dallasbru@2001:470:69fc:105::2:8c0d> has quit IRC (Quit: User was banned) | 17:32 | |
*** amitk <amitk!~amit@103.208.69.37> has quit IRC (Ping timeout: 265 seconds) | 18:05 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:06 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 265 seconds) | 18:19 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 18:19 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 244 seconds) | 18:24 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 18:24 | |
*** rcw <rcw!~rcwoolley@216.154.26.130> has joined #yocto | 18:37 | |
*** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 18:38 | |
*** cmd <cmd!~cmd@user/cmd> has quit IRC (Remote host closed the connection) | 18:42 | |
*** rcw <rcw!~rcwoolley@216.154.26.130> has quit IRC (Quit: Leaving) | 18:43 | |
*** Mamta_ <Mamta_!uid253919@id-253919.lymington.irccloud.com> has joined #yocto | 18:47 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 18:54 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 18:55 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 18:55 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 18:55 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 250 seconds) | 18:59 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 18:59 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:00 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:00 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 252 seconds) | 19:03 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 19:04 | |
*** odra_ <odra_!~odra@179.110.183.71> has quit IRC (Ping timeout: 268 seconds) | 19:04 | |
fray | package manager solutions, IMHO, are only useful for larger devices. OS Tree, image based, etc are much better for embedded systems | 19:27 |
fray | BUT package managers provide a ton of metadata that can be used to drive the other systems | 19:27 |
fray | well remember layers/recipe extensions are designed into teh system so they can be added AFTER the initial build/release as updates... | 19:28 |
fray | but it also means to work well, layers/recipe extensions need to be functionally targeted.. which is a huge problem, not as bad as it WAS, not as good as it could be | 19:29 |
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 268 seconds) | 19:30 | |
*** fuzzybear396517 <fuzzybear396517!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto | 19:31 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 244 seconds) | 19:34 | |
LetoThe2nd | yo dudX | 19:35 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:38 | |
fray | ohh the other thing I did this summer.. setup a 320 watt solar panel in my field, along with a Mesh WiFi (PoE) unit, a security camera.. PoE switch and two more mesh WiFi units.. | 19:39 |
fray | oops | 19:39 |
LetoThe2nd | fray: now you just have to tell us which of the components runs YOEP | 19:40 |
fray | alas none of them.. the security cam and APs are ubiquity.. so they're running Linux, but it's some debian based thing | 19:40 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 19:41 | |
LetoThe2nd | meh. böring. | 19:42 |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 19:45 | |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 19:58 | |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 19:59 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 252 seconds) | 20:12 | |
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 20:21 | |
*** nerdboy <nerdboy!~nerdboy@47.143.129.241> has joined #yocto | 20:25 | |
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has quit IRC (Remote host closed the connection) | 20:29 | |
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto | 20:45 | |
*** odra_ <odra_!~odra@2804:431:c7e0:f650:1e05:f109:83ea:6f69> has joined #yocto | 20:46 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 20:50 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 20:50 | |
*** fuzzybear396517 <fuzzybear396517!~fuzzybear@2001:420:c0c0:1003::49b> has quit IRC (Ping timeout: 252 seconds) | 21:00 | |
*** Mamta_ <Mamta_!uid253919@id-253919.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 21:03 | |
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto | 21:05 | |
*** sef <sef!~sef@46.221.0.162> has joined #yocto | 21:09 | |
*** florian_kc is now known as florian | 21:16 | |
*** sef <sef!~sef@46.221.0.162> has quit IRC (Quit: Client closed) | 21:21 | |
*** odra_ <odra_!~odra@2804:431:c7e0:f650:1e05:f109:83ea:6f69> has quit IRC (Remote host closed the connection) | 21:30 | |
*** odra_ <odra_!~odra@2804:431:c7e0:f650:1e05:f109:83ea:6f69> has joined #yocto | 21:30 | |
*** odra__ <odra__!~odra@179.110.183.71> has joined #yocto | 21:56 | |
*** odra_ <odra_!~odra@2804:431:c7e0:f650:1e05:f109:83ea:6f69> has quit IRC (Remote host closed the connection) | 21:58 | |
*** rabbi[11] <rabbi[11]!~rabbi11]@54-240-198-34.amazon.com> has joined #yocto | 22:09 | |
*** kscherer <kscherer!~kscherer@dsl-173-206-238-19.tor.primus.ca> has quit IRC (Quit: Konversation terminated!) | 22:24 | |
*** florian <florian!~florian@dynamic-002-244-068-030.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 22:26 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: xmn) | 22:52 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:59 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:02 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:03 | |
kergoth | rburton: don't know if you use bb anymore, i stopped ages ago, but went ahead and fixed latest, list, set-layer-path, and edit. search, whatdepends, and show are still busted. but of course show is obsolete really in favor of getvar and/or var, and i don't know that search was that useful to begin with.. i think i'll try fixing whatdepends to use the generated dependency graph info instead of taskdata directly next. | 23:06 |
kergoth | should really add an equivalent to gitconfig for aliases.. | 23:06 |
kergoth | need to scrap most of bbcmd.py, its subclass of Tinfoil isn't needed and is mostly broken anyway | 23:07 |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:13 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:13 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:14 | |
*** ak77_ <ak77_!~ak77@93-103-41-115.dynamic.t-2.net> has quit IRC (Ping timeout: 268 seconds) | 23:31 | |
*** ak77 <ak77!~ak77@93-103-41-115.dynamic.t-2.net> has joined #yocto | 23:31 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:42 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:43 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:47 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:47 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:48 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:49 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 252 seconds) | 23:49 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 23:49 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:50 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:51 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 23:52 | |
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:53 | |
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 265 seconds) | 23:59 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!