Tuesday, 2022-09-27

*** 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 #yocto00: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 #yocto01:12
*** rber|res <rber|res!~rber|res@62-46-89-217.adsl.highway.telekom.at> has joined #yocto01: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 #yocto01: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 chep01: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 #yocto01: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 #yocto01: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 #yocto01:54
*** abdullahie[m] <abdullahie[m]!~abdullahi@2001:470:69fc:105::2:8af7> has joined #yocto02:02
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto02: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 #yocto03: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 #yocto03: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 #yocto03:29
*** cmpdude <cmpdude!~cmpdude@14-201-56-110.static.tpgi.com.au> has joined #yocto03:45
cmpdudehi 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 #yocto04: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 #yocto04:54
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto04:59
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)05:48
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto05: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 #yocto06:00
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)06:03
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto06:04
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06: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 #yocto06: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 #yocto06:14
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto06: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 #yocto06:37
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto06:44
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)06:44
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto06:44
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06: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 mckoan06:47
mckoangood morning06:47
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto06: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 #yocto07: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 #yocto07:04
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:10d6:cd9b:247:1e52> has joined #yocto07:05
*** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:d4cc:dbff:fe3c:3b93> has joined #yocto07:06
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto07: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 #yocto07:09
*** Ram-Z <Ram-Z!~Ram-Z@li1814-254.members.linode.com> has joined #yocto07:12
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto07:15
tomzy_0Hi07:16
tomzy_0I 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 get07: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 done07: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 directory07:18
tomzy_0I tried to reproduce this error in different environment, take Ubuntu 22.04 with gcc v11 (same as in Yocto) and could compile without problems07:19
tomzy_0So 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 #yocto07:20
*** Maxxed52 <Maxxed52!~Maxxed@nrgt.net> has quit IRC (Quit: Ping timeout (120 seconds))07:20
*** Maxxed52 <Maxxed52!~Maxxed@nrgt.net> has joined #yocto07:21
*** mvlad <mvlad!~mvlad@2a02:2f08:4605:ca00:24d7:51ff:fed6:906d> has joined #yocto07: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 #yocto07: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 #yocto07:44
*** zpfvo1 <zpfvo1!~fvo@i59F5CDB4.versanet.de> has joined #yocto07:45
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07: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 #yocto07:51
*** jclsn <jclsn!~jclsn@2a04:4540:6511:2900:2ce:39ff:fecf:efcd> has joined #yocto07: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 #yocto07:53
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto08:05
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto08:19
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)08:40
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto08: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 #yocto08: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 #yocto08:53
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto09:02
*** seninha <seninha!~seninha@user/seninha> has joined #yocto09: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 #yocto09:27
fuzzybear396544I'm using bitbake -c unpack <recipe> and I want to view the result of this operation.09:27
fuzzybear396544How can I have the operations printed to STDOUT so I can see in which directory the unpacked files exist?09:27
fuzzybear396544Alternatively, how can I print the script that's running for do_unpack09:28
fuzzybear396544Based 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
NP9look for the temp subfolder, there should be a log.do_unpack which should contain the output of that task09:34
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)09:35
fuzzybear396544Oh, yeah, I found that! Thanks!09:36
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto09:36
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection)09:36
fuzzybear396544NP9 What's the difference between <recipe>/image and <recipe>/package ?09:36
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto09:36
qschulzfuzzybear396544: the sources are unpacked by default in S09:41
qschulzfuzzybear396544: except for the file:// ones in SRC_URI, where it's put into WORKDIR IIRC09:42
qschulzso you can find the path with bitbake-getvar tool or bitbake -e <recipe>09:42
NP9I 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 about09:46
fuzzybear396544qschulz You're right about file:// ones, apparently.09:46
fuzzybear396544NP9 It's weird because bitbake <recipe> populates both package/ and image/ with my do_install dummy outptu09:46
fuzzybear396544s/outptu/output09:46
fuzzybear396544qschulz 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
fuzzybear396544qschulz bitbake-getvar -r <recipe> S worked great! Thanks a lot!09:48
qschulzfuzzybear396544: https://docs.yoctoproject.org/overview-manual/concepts.html#configuration-compilation-and-staging and https://docs.yoctoproject.org/overview-manual/concepts.html#package-splitting09:49
qschulzI do not know why we need the package directory over the image directory though09:49
fuzzybear396544qschulz Thanks for the links. What do you mean "why we need X directory over Y directory"?09:50
fuzzybear396544Do you mean "over" like "in favor of" or "over" like "in addition to" or over like "parent directory"?09:50
qschulzfuzzybear396544: in addition to09:51
fuzzybear396544Oh, okay.09:51
rburtonNP9: yeah you're wrong :)09:52
fuzzybear396544I 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 #yocto09:56
NP9rburton looking at the links do_install uses /image and do_package uses /package before breaking it up in different packages09:57
RPrburton: one CVE now. Can you guess which recipe?09:58
rburtonhaha09:58
*** starblue <starblue!~juergen@dslb-094-220-106-043.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds)09:58
rburtonNP9: correct09:58
*** starblue <starblue!~juergen@dslb-094-220-106-043.094.220.pools.vodafone-ip.de> has joined #yocto10:00
NP9rburton 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 #yocto10:01
rburtonNP9: because do_package does work to the tree, so it has to copy10:01
NP9ye 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_0Hi, 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 get10: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 done10: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 directory10:07
tomzy_0I tried to reproduce this error in different environment, take Ubuntu 22.04 with gcc v11 (same as in Yocto) and could compile without problems10:07
tomzy_0So 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 #yocto10:08
fuzzybear39653I 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
rburtontomzy_0: you _need_ the sysroot to be passed to gcc, so i'd blame the makefile10:09
rburtonfuzzybear39653: do_unpack[prefunc]10:09
fuzzybear39653:pray:10:09
rburtonprepend 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
fuzzybear39653rburton [postfunc] for _append?10:10
fuzzybear39653Right now I have bb.build.exec_func('foo_shell_func', d) in my _prepend .10:10
tomzy_0rburton I thought that too, but the sysroot is set inside recipe by adding the following10:10
tomzy_0    CGO_CFLAGS=\"--sysroot=${RECIPE_SYSROOT}\" \10:10
tomzy_0    CGO_LDFLAGS=\"--sysroot=${RECIPE_SYSROOT}\" \10:10
tomzy_0What's annoying is that I do not even know, with which files linker has a problem10: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 #yocto10:20
fuzzybear396522I have a recipe for which I need to obtain the version number of another recipe.10:21
fuzzybear396522Is there a way to accomplish this?10:21
rburtonno10:21
fuzzybear396522I have to hard-code the value?10:22
rburtonyou could write the versions to the rootfs and fetch them at runtime10:30
rburtonwhat 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
fuzzybear396522rburton 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
fuzzybear396522So, 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
fuzzybear396522So, 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 #yocto10:39
fuzzybear396522I'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
fuzzybear396522So, the build fails.10:39
fuzzybear396522That is, one of the build products is a binary used to compete the build.10:39
fuzzybear396522Butt, that binary can't be executed.10:39
fuzzybear396522Using `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
fuzzybear396522What do people normally do in this case?10:40
fuzzybear396522s/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 #yocto10: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 #yocto10: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 #yocto11: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 #yocto11:06
*** BobPungartnik <BobPungartnik!~Pung@177.41.202.109> has joined #yocto11:07
rburtonfuzzybear396527: 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 #yocto11: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 #yocto11: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 #yocto11:22
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto11:22
fuzzybear396545rburton 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 #yocto11: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 #yocto11:33
*** cmd <cmd!~cmd@user/cmd> has joined #yocto11:35
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has joined #yocto11: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 #yocto11:40
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds)11:41
rburtonthere's no standard for those, which makes it fun11:42
rburtonautotools _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
rburtonbetter advice given if you can point to the makefile11:42
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)11:43
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto11:43
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto11: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 #yocto11: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 #yocto11: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 #yocto12:04
*** fuzzybear396541 <fuzzybear396541!~fuzzybear@2001:420:c0c0:1003::49b> has joined #yocto12:08
fuzzybear396541I have a DISTRO_FEATURES="foo" and in a <recipe>.bbappend I have DEPENDS:append:foo = <dependency>12:09
fuzzybear396541But, when I bitbake -g <recipe> I don't see <dependency> in the output.12:09
fuzzybear396541I tried putting DEPENDS:append:foo in <recipe>.bb. I also tried DEPENDS_append_df-foo = <dependency> .12:10
fuzzybear396541None of those worked.12:10
fuzzybear396541How should I specify that <recipe>.bb depends on <dependency> when DISTRO_FEATURES="foo" is present.12:11
rburtoncheck distro features is set to what you expect12:11
rburtonbut distro features are not overrides12:11
rburtonso :foo won't work12:12
fuzzybear396541It's a space-separated list in conf/local.conf that has DISTRO_FEATURES="foo qux quz"12:12
rburtonsee eg classes-recipe/update-rc.d.bbclass:DEPENDS:append:class-target = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', ' update-rc.d initscripts', '', d)}"12:12
rburtonyou won't need the class-target bit12:12
fuzzybear396541qschulz recommended this syntax yesterday.12:12
fuzzybear396541rburton Okay, so.I need to execute bb.utls.contains12:13
fuzzybear396541Is this better in <recipe>.bb or <recipe>.bbappend ?12:14
fuzzybear396541Seems like it could go in either place.12:14
rburtonif you own the recipe, there's no need to write a bbappend12:14
fuzzybear396541I own it, yeah.12:14
fuzzybear396541Okay. Thanks.12:14
fuzzybear396541rburton 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
fuzzybear396541Thanks 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 #yocto12: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 #yocto12: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 #yocto12: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 #yocto13:07
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto13: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 #yocto13: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 #yocto13: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 #yocto13: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 #yocto13:54
*** mrnuke <mrnuke!~mrnuke@c-98-197-58-203.hsd1.tx.comcast.net> has joined #yocto13: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 #yocto14:07
*** seninha <seninha!~seninha@user/seninha> has joined #yocto14:08
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 268 seconds)14:09
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto14:11
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)14:18
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto14: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 #yocto14:20
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto14:22
rfuentessquestion. bb.utils.contains_any how reliable is for checking settings from the image recipe   in other packages recipes ?14:26
rfuentessI'm a little confused due the lifetime of the environment variables14:26
rburtonrecipes are isolated from each other14:27
rburtonthere's no concept of variables being set in a recipe and then being used in an image14:27
rburtonan image is a recipe, and recipes are isolated14:27
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto14: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
rfuentessyeah. that is what I learned in the hard way, but then I was requested to evaluate that tool.14:40
JPEWdenix, Crofton: I've just release Pyrex 1.7.0 which adds Ubuntu 22.04 and Yocto 4.0 compatibility14:42
CroftonJPEW: thanks14: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 #yocto14:52
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 265 seconds)14:52
*** Guest66 <Guest66!~Guest66@mail.digitalendoscopy.de> has joined #yocto14:52
*** Guest66 <Guest66!~Guest66@mail.digitalendoscopy.de> has quit IRC (Client Quit)14:53
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto14:53
*** mckoan is now known as mckoan|away14:53
fabatera[m]My python package inherits pypi15: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.gz15: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
rburtonfabatera[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 pypi15: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 #yocto15:22
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 265 seconds)15:22
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto15:24
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Ping timeout: 246 seconds)15:27
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has joined #yocto15:29
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:30
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 246 seconds)15:32
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto15:35
*** florian_kc <florian_kc!~florian@dynamic-002-244-068-030.2.244.pool.telefonica.de> has joined #yocto15:45
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)15:49
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto15:49
denixJPEW: great! I'll be testing it today15:53
*** thomasd13 <thomasd13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 268 seconds)16:07
fuzzybear396531It 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
fraywhat is the symptom?  The most common faults are using the wrong compiler, not passing the CFLAGS (or LDFLAGS), and programs hard coding them16:23
rburtonfuzzybear396531: lots of recipes do this, so i still blame the makefile16: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
fuzzybear396531fray 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
rburtonfuzzybear396531: for example if you're using recipe-sysroot during a native build then it's doing something very wrong16:24
fuzzybear396531build-shared3% ../../recipe-sysroot/lib/ld-2.31.so --list ./$BINARY_THAT_NEEDS_TO_RUN16: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
fuzzybear396531fray No, hard coding -L into /usr/lib16:25
fuzzybear396531Not doing that.16:25
rburtoncan you point us at a git repo?16:25
fuzzybear396531rburton no :(  . It's corporate work.16:25
frayif 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
rburtonwell, don't ask the target loader about the linkage, because that's not the loader that will be used16:26
frayalso 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
fuzzybear396531I 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
fraysysroot-native is programs that run on the host, compiled for the host, USUALLY to assist in cross compilng..16:27
fraysysroot is target binaries16:27
fuzzybear396531fray 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
fraysysroot-native expects a custom environment to run.  w/o the environment it may try to run against host libraries16:27
rburtonfuzzybear396531: just do LD_TRACE_LOADED_OBJECTS1= ./binary-to-run16:27
fuzzybear396531fray Okay, then I think it makes sense to use it in this case.16:27
rburton(in a devshell)16:27
fraysysroot (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
frayyou need to chroot into the directory and run it16:27
fuzzybear396531rburton What's a devshell? That command fails in a normal shall (file not found).16:28
fraysysroot-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
fuzzybear396531fray If I chroot into sysroot-native then the WORKDIR is out of my directory tree.16:29
fraysysroot_-native_ doesn't need chroot..  _sysroot_ does16:29
fuzzybear396531This binary needs to execute on the build machine as a part of the compilation phase.16:29
fuzzybear396531So, I think it makes sense to use the linker from sysroot-native.16:29
frayignore the architecture 'sysroot' is targeting..  always assume it's different16:29
fuzzybear396531For sure. No problem.16:29
fuzzybear396531Yeah, I'm not considering sysroot at all. I haven't looked at it.16:29
fraythe 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 right16:30
frayOk, so what are you building.. a _HOST_ tool, or a _TARGET_ tool?16:30
fuzzybear396531I'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
fuzzybear396531Yeah, sysroot-native has the right libc.16:31
fuzzybear396531If I LD_PRELOAD that libc then the executable runs.16:31
frayok, so then you are down to compiler (need the YP native compiler) and the sysroot-native for your build(s)16:31
fuzzybear396531What's the YP native compiler?16:32
fraythis 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
fuzzybear396531How can I access a dev shell?16:32
fraythe key thing is (objdump can show you) what ld.so is the sysroot-native picking up?16:32
fuzzybear396531Which options should I pass to objdump?16:33
frayjust walking through my own build:16:33
fraytmp/work/versal_net_generic-xilinx-linux/petalinux-image-everything/1.0-r0/recipe-sysroot-native/bin16:33
frayobjdump -x cpio16:33
frayDynamic Section: NEEDED               libc.so.6 RUNPATH              $ORIGIN/../usr/lib:$ORIGIN/../lib16:34
frayfile cpio16:34
fraycpio: 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, stripped16:34
fraythats 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 ORIGIN16:34
fuzzybear396531Nah, 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
fuzzybear396531objdump -x didn't print that path... Weird.16:36
frayok.. so if you get an interpreter of /lib/ld-linux then either the linker or compiler was wrong.16:36
frayOR the ldflags were wrong..16:36
fraybasically the binary is linked to the wrong ld.so (even if the other parts are right) that is controlled via the LDFLAGS, I think16:36
fuzzybear396531Okay, this is great to know. Thanks a lot.16:37
fuzzybear396531How can I enter a dev shell, though?16:37
fuzzybear396531That sounds really useful.16:37
fuzzybear396531Can I run do_compile from there?16:37
fraylooking at bitbake cpio-native -e, I see:16:38
frayexport 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-dtags16: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/lib16:38
rburtonfuzzybear396531: 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-undefined16: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
frayit's that last -Wl,--dynamic-linker that sets the values16:38
fuzzybear396531rburton for sure, but it's a little long.16:38
frayso if LDFLAGS isn't being handled, you won't get the right link16:38
fuzzybear396531fray Thanks a lot!16:38
rburtonfuzzybear396531: just the lines that builds that tool should be fine16: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
fuzzybear396531For sure. Even that is a bit long, though.16:39
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto16:39
frayfor devshell.. bitbake -c devshell <your recipe>16:39
fuzzybear396531fray I've been living in bitbake -e all day (but mostly looking at CFLAGS). This is really helpful.16:39
fuzzybear396531fray Thanks!16:39
frayya, 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 LDFLAGS16:40
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit)16:40
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto16:40
frayhopefully this can help unblock you16:40
fuzzybear396531rburton it branches based on the presence of HOST_CC versus CC so it looks a little funky:16:42
fuzzybear396531x86_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 -fPIC16: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_ASM16:42
fuzzybear396531-DECP_NISTZ256_ASM $BINARY.o; \16:42
fuzzybear396531else \16:42
fuzzybear396531          -o ../$BINARY -I../../include -I../../crypto $BINARY.c ../../crypto/sha/sha1dgst.c ; \16:42
fuzzybear396531fi16:42
fuzzybear396531fray I think it will.16:42
*** zpfvo <zpfvo!~fvo@i59F5CDB4.versanet.de> has quit IRC (Quit: Leaving.)16:42
rburtonfuzzybear396531: that's using target flags not BUILD_16:42
fuzzybear396531rburton I'm sorry. I don't understand.16:42
rburtonfuzzybear396531: 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 etc16:43
frayThe recipe will DEFAULT to 'target' style..  When you inherit 'native', it switching LDFLAGS (and CFLAGS) to use the "BUILD"/host versions16:43
rburtonthat is definitely using LDFLAGS (as it passes --sysroot)16:43
fuzzybear396531Ohhhhh16:43
rburtonwell, --sysroot implies CC not BUILD_CC16:43
rburtoni'm presuming this is a target recipe that needs to build a single binary to run on the host16:44
frayrburton, ya I missed that.. you are right16:44
fuzzybear396531rburton Yeah, exactly.16:44
rburtonthe makefile needs to be cross-aware and know how to use a different compiler for host binaries vs target binaries16:44
fuzzybear396531rburton Okay, so the best thing to do would be to swap CC for BUILD_CC, here?16:45
fuzzybear396531And LDFLAGS for BUILD_LDFLAGS, etc.?16:45
rburtonis this plain makefiles or autotools or what?16:45
fraythat swap happens on the YP side of things.. (or should)16:45
fuzzybear396531rburton It's a plain makefile.16:45
fraythe makefile should just use CC, CFLAGS, LDFLAGS, etc. (unless it's a cross compiler)16:45
fraythen it's up to the recipe logic to switch the value of 'CC" from the target version to the 'native' version16:46
rburtonthe one rule that generates this binary should use CC_FOR_BUILD instead of CC.  CC_FOR_BUILD can default to CC16: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
fuzzybear396531fray It does use CC, CFLAGS, LDFLAGS, etc. unless HOST_CC is present.16:46
fuzzybear396531That's how the target's Makefile logic is expressed.16:46
rburtonactually BUILD_CC is exported, so use that name and it just works16:47
frayok16:47
fuzzybear396531rburton Okay, I'll swap out the CC stuff for BUILD_CC stuff.16:47
rburtonthere's a trick you can do with make16:47
fuzzybear396531rburton give me all the tricks!16:47
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto16:48
rburtoniirc, mybinary: CC=${BUILD_CC}16:49
rburtonwhere mybinary is the target for your binary16:49
rburtonrepeat for CFLAGS etc16:49
fuzzybear396531On new lines or comma-separated?16:49
rburtonand provide a default BUILD_CC?=$CC16:49
fuzzybear396531That's pretty slick.16:49
rburtonhttps://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html suggests multiple assignments16:50
rburtonyou're just overriding the variables for a specific target16:50
fuzzybear396531Yeah, and it avoids overwriting all the logic below the target.16:50
rburtonespecially as you've written a good makefile which doesn't have a %o:%.c rule, right? :)16:50
rburtoni'll also point out here that make is terrible, use something like meson: it's better and handles stuff like this transparently16: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 #yocto16:54
*** PhoenixMage <PhoenixMage!~phoenix@206.83.113.58> has joined #yocto16:55
fuzzybear396531Well, so I didn't write this Makefile.16:55
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto16:56
fuzzybear396531But, even then I don't know if %o:%.c is good.....16:56
fuzzybear396531Meson 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
rburtonyes16:56
rburtonyou just say native:true16:57
fuzzybear396531Oh, I see.16:58
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto16:58
fuzzybear396531Yeah, 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 #yocto17: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 #yocto17:16
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:17
*** seninha <seninha!~seninha@user/seninha> has joined #yocto17:17
*** Guest12 <Guest12!~Guest12@80.174.116.206.dyn.user.ono.com> has joined #yocto17: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 #yocto18: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 #yocto18: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 #yocto18:24
*** rcw <rcw!~rcwoolley@216.154.26.130> has joined #yocto18:37
*** grma <grma!~gruberm@80.93.38.128> has joined #yocto18: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 #yocto18:47
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)18:54
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto18: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 #yocto18: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 #yocto18:59
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)19:00
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto19: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 #yocto19:04
*** odra_ <odra_!~odra@179.110.183.71> has quit IRC (Ping timeout: 268 seconds)19:04
fraypackage manager solutions, IMHO, are only useful for larger devices.  OS Tree, image based, etc are much better for embedded systems19:27
frayBUT package managers provide a ton of metadata that can be used to drive the other systems19:27
fraywell remember layers/recipe extensions are designed into teh system so they can be added AFTER the initial build/release as updates...19:28
fraybut 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 be19: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 #yocto19:31
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 244 seconds)19:34
LetoThe2ndyo dudX19:35
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor)19:38
frayohh 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
frayoops19:39
LetoThe2ndfray: now you just have to tell us which of the components runs YOEP19:40
frayalas none of them.. the security cam and APs are ubiquity.. so they're running Linux, but it's some debian based thing19:40
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto19:41
LetoThe2ndmeh. 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 #yocto19: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 #yocto20: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 #yocto20:45
*** odra_ <odra_!~odra@2804:431:c7e0:f650:1e05:f109:83ea:6f69> has joined #yocto20: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 #yocto20: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 #yocto21:05
*** sef <sef!~sef@46.221.0.162> has joined #yocto21:09
*** florian_kc is now known as florian21: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 #yocto21:30
*** odra__ <odra__!~odra@179.110.183.71> has joined #yocto21: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 #yocto22: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 #yocto22: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 #yocto23:03
kergothrburton: 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
kergothshould really add an equivalent to gitconfig for aliases..23:06
kergothneed to scrap most of bbcmd.py, its subclass of Tinfoil isn't needed and is mostly broken anyway23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23: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 #yocto23:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!