leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
sakoman has quit [Quit: Leaving.]
leon-anavi has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 248 seconds]
chep` has joined #yocto
chep has quit [Ping timeout: 265 seconds]
chep` is now known as chep
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
abdullahie[m] has joined #yocto
sakoman has joined #yocto
abdullahie[m] has quit [K-Lined]
KurtKiefer[m] has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
cmpdude has joined #yocto
<cmpdude>
hi all - anyone know how to persuade the linux-stable recipe to build the tools in /tools/iio?
cmd has quit [Ping timeout: 252 seconds]
<rabbi[11]>
fabatera[m]: thanks a ton forr all the steps.
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 265 seconds]
mrnuke_ has quit [Ping timeout: 265 seconds]
rabbi[11] has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Ram-Z has quit [Ping timeout: 246 seconds]
thomasd13 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
nemik has joined #yocto
alessioigor has joined #yocto
vmeson has quit [Ping timeout: 264 seconds]
zkrx has quit []
zkrx has joined #yocto
rfuentess has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w has joined #yocto
xmn has quit [Quit: ZZZzzz…]
mckoan|away is now known as mckoan
<mckoan>
good morning
xmn has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zkrx has quit []
goliath has quit [Quit: SIGSEGV]
vladest has quit [Quit: vladest]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
vladest has joined #yocto
zkrx has joined #yocto
zpfvo has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
Ram-Z has joined #yocto
tomzy_0 has joined #yocto
<tomzy_0>
Hi
<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
<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
<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
<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
<tomzy_0>
So are there some default flags that are being added to the cross compiler which causes the linker to fail?
NP9 has joined #yocto
Maxxed52 has quit [Quit: Ping timeout (120 seconds)]
Maxxed52 has joined #yocto
mvlad has joined #yocto
cmpdude has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rber|res has quit [Ping timeout: 265 seconds]
manuel1985 has joined #yocto
zpfvo1 has joined #yocto
goliath has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
rber|res has joined #yocto
jclsn has joined #yocto
jclsn has quit [Client Quit]
jclsn has joined #yocto
leon-anavi has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo1 has quit [Ping timeout: 250 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
seninha has joined #yocto
manuel1985 has quit [Remote host closed the connection]
fuzzybear396544 has joined #yocto
<fuzzybear396544>
I'm using bitbake -c unpack <recipe> and I want to view the result of this operation.
<fuzzybear396544>
How can I have the operations printed to STDOUT so I can see in which directory the unpacked files exist?
<fuzzybear396544>
Alternatively, how can I print the script that's running for do_unpack
<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.
<NP9>
look for the temp subfolder, there should be a log.do_unpack which should contain the output of that task
alessioigor has quit [Quit: alessioigor]
<fuzzybear396544>
Oh, yeah, I found that! Thanks!
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<fuzzybear396544>
NP9 What's the difference between <recipe>/image and <recipe>/package ?
alessioigor has joined #yocto
<qschulz>
fuzzybear396544: the sources are unpacked by default in S
<qschulz>
fuzzybear396544: except for the file:// ones in SRC_URI, where it's put into WORKDIR IIRC
<qschulz>
so you can find the path with bitbake-getvar tool or bitbake -e <recipe>
<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
<fuzzybear396544>
qschulz You're right about file:// ones, apparently.
<fuzzybear396544>
NP9 It's weird because bitbake <recipe> populates both package/ and image/ with my do_install dummy outptu
<fuzzybear396544>
s/outptu/output
<fuzzybear396544>
qschulz bitbake-getvar seems like a great tool! Let me read the docs!
zpfvo has quit [Ping timeout: 268 seconds]
<fuzzybear396544>
qschulz bitbake-getvar -r <recipe> S worked great! Thanks a lot!
fuzzybear396544 has quit [Quit: Ping timeout (120 seconds)]
<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
<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
<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
<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
<tomzy_0>
So are there some default flags that are being added to the cross compiler which causes the linker to fail?
fuzzybear39653 has joined #yocto
<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?
<rburton>
tomzy_0: you _need_ the sysroot to be passed to gcc, so i'd blame the makefile
<rburton>
fuzzybear39653: do_unpack[prefunc]
<fuzzybear39653>
:pray:
<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.
<rburton>
(look in the docs how to use them)
<fuzzybear39653>
rburton [postfunc] for _append?
<fuzzybear39653>
Right now I have bb.build.exec_func('foo_shell_func', d) in my _prepend .
<tomzy_0>
rburton I thought that too, but the sysroot is set inside recipe by adding the following
<tomzy_0>
What's annoying is that I do not even know, with which files linker has a problem
fuzzybear39653 has quit [Quit: Ping timeout (120 seconds)]
fuzzybear396522 has joined #yocto
<fuzzybear396522>
I have a recipe for which I need to obtain the version number of another recipe.
<fuzzybear396522>
Is there a way to accomplish this?
<rburton>
no
<fuzzybear396522>
I have to hard-code the value?
<rburton>
you could write the versions to the rootfs and fetch them at runtime
<rburton>
what happens if you upgrade the other recipe: is the first recipe definitely going to rebuild?
ecdhe has quit [Ping timeout: 250 seconds]
<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.
<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)
<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).
ecdhe has joined #yocto
<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.
<fuzzybear396522>
So, the build fails.
<fuzzybear396522>
That is, one of the build products is a binary used to compete the build.
<fuzzybear396522>
Butt, that binary can't be executed.
<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.
<fuzzybear396522>
What do people normally do in this case?
<fuzzybear396522>
s/looks dynamically, linked, so my shared library paths/looks dynamically linked, and I guess that my shared library paths/
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
fuzzybear396522 has quit [Quit: Ping timeout (120 seconds)]
fuzzybear396527 has joined #yocto
manuel1985 has quit [Ping timeout: 265 seconds]
ptsneves has joined #yocto
BobPungartnik has joined #yocto
<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.
BobPungartnik has quit [Client Quit]
fuzzybear396527 has quit [Quit: Ping timeout (120 seconds)]
<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.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
cmd has joined #yocto
DvorkinDmitry has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
camus has quit [Ping timeout: 265 seconds]
<rburton>
there's no standard for those, which makes it fun
<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.
<rburton>
better advice given if you can point to the makefile
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
camus has joined #yocto
fuzzybear396545 has quit [Quit: Ping timeout (120 seconds)]
zpfvo has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
fuzzybear396541 has joined #yocto
<fuzzybear396541>
I have a DISTRO_FEATURES="foo" and in a <recipe>.bbappend I have DEPENDS:append:foo = <dependency>
<fuzzybear396541>
But, when I bitbake -g <recipe> I don't see <dependency> in the output.
<fuzzybear396541>
I tried putting DEPENDS:append:foo in <recipe>.bb. I also tried DEPENDS_append_df-foo = <dependency> .
<fuzzybear396541>
None of those worked.
<fuzzybear396541>
How should I specify that <recipe>.bb depends on <dependency> when DISTRO_FEATURES="foo" is present.
<rburton>
check distro features is set to what you expect
<rburton>
but distro features are not overrides
<rburton>
so :foo won't work
<fuzzybear396541>
It's a space-separated list in conf/local.conf that has DISTRO_FEATURES="foo qux quz"
<fuzzybear396541>
qschulz recommended this syntax yesterday.
<fuzzybear396541>
rburton Okay, so.I need to execute bb.utls.contains
<fuzzybear396541>
Is this better in <recipe>.bb or <recipe>.bbappend ?
<fuzzybear396541>
Seems like it could go in either place.
<rburton>
if you own the recipe, there's no need to write a bbappend
<fuzzybear396541>
I own it, yeah.
<fuzzybear396541>
Okay. Thanks.
<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)}"
<fuzzybear396541>
Thanks a lot!
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
tomzy_0 has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
fuzzybear396541 has quit [Quit: Ping timeout (120 seconds)]
xmn has joined #yocto
seninha has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 268 seconds]
seninha has joined #yocto
zpfvo has joined #yocto
NP9 has quit [Ping timeout: 252 seconds]
florian has quit [Quit: Ex-Chat]
kscherer has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
marc1 has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
mrnuke has joined #yocto
seninha has quit [Quit: Leaving]
grma has quit [Ping timeout: 252 seconds]
xmn has quit [Ping timeout: 244 seconds]
xmn has joined #yocto
seninha has joined #yocto
ecdhe has quit [Ping timeout: 268 seconds]
ecdhe has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ecdhe has quit [Ping timeout: 250 seconds]
fuzzybear396531 has joined #yocto
ecdhe has joined #yocto
<rfuentess>
question. bb.utils.contains_any how reliable is for checking settings from the image recipe in other packages recipes ?
<rfuentess>
I'm a little confused due the lifetime of the environment variables
<rburton>
recipes are isolated from each other
<rburton>
there's no concept of variables being set in a recipe and then being used in an image
<rburton>
an image is a recipe, and recipes are isolated
ecdhe_ has joined #yocto
rob_w has quit [Quit: Leaving]
ecdhe has quit [Ping timeout: 268 seconds]
goliath has quit [Quit: SIGSEGV]
seninha has quit [Ping timeout: 265 seconds]
<rfuentess>
yeah. that is what I learned in the hard way, but then I was requested to evaluate that tool.
<JPEW>
denix, Crofton: I've just release Pyrex 1.7.0 which adds Ubuntu 22.04 and Yocto 4.0 compatibility
<Crofton>
JPEW: thanks
dev1990 has quit [Quit: Konversation terminated!]
marc1 has joined #yocto
ecdhe_ has quit [Ping timeout: 265 seconds]
Guest66 has joined #yocto
Guest66 has quit [Client Quit]
ecdhe has joined #yocto
mckoan is now known as mckoan|away
<fabatera[m]>
My python package inherits pypi
<fabatera[m]>
Fetch is failing to get the tarball prepended and is not trying the github url (build error)
<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
<fabatera[m]>
Is it a yocto bug?
xmn has quit [Ping timeout: 265 seconds]
<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
<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).
xmn has joined #yocto
ecdhe has quit [Ping timeout: 265 seconds]
ecdhe has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
goliath has joined #yocto
ecdhe has quit [Ping timeout: 246 seconds]
ecdhe has joined #yocto
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<denix>
JPEW: great! I'll be testing it today
thomasd13 has quit [Ping timeout: 268 seconds]
<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.
<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
<rburton>
fuzzybear396531: lots of recipes do this, so i still blame the makefile
rfuentess has quit [Remote host closed the connection]
<fray>
(i.e. hard coding -L/usr/lib for instance WILL cause issues..)
<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.
<rburton>
fuzzybear396531: for example if you're using recipe-sysroot during a native build then it's doing something very wrong
<fuzzybear396531>
fray No, hard coding -L into /usr/lib
<fuzzybear396531>
Not doing that.
<rburton>
can you point us at a git repo?
<fuzzybear396531>
rburton no :( . It's corporate work.
<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..
<rburton>
well, don't ask the target loader about the linkage, because that's not the loader that will be used
<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)
<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?
<fray>
sysroot-native is programs that run on the host, compiled for the host, USUALLY to assist in cross compilng..
<fray>
sysroot is target binaries
<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.
<fray>
sysroot-native expects a custom environment to run. w/o the environment it may try to run against host libraries
<rburton>
fuzzybear396531: just do LD_TRACE_LOADED_OBJECTS1= ./binary-to-run
<fuzzybear396531>
fray Okay, then I think it makes sense to use it in this case.
<rburton>
(in a devshell)
<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..
<fray>
you need to chroot into the directory and run it
<fuzzybear396531>
rburton What's a devshell? That command fails in a normal shall (file not found).
<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 /
<fuzzybear396531>
fray If I chroot into sysroot-native then the WORKDIR is out of my directory tree.
<fray>
sysroot_-native_ doesn't need chroot.. _sysroot_ does
<fuzzybear396531>
This binary needs to execute on the build machine as a part of the compilation phase.
<fuzzybear396531>
So, I think it makes sense to use the linker from sysroot-native.
<fray>
ignore the architecture 'sysroot' is targeting.. always assume it's different
<fuzzybear396531>
For sure. No problem.
<fuzzybear396531>
Yeah, I'm not considering sysroot at all. I haven't looked at it.
<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
<fray>
Ok, so what are you building.. a _HOST_ tool, or a _TARGET_ tool?
<fuzzybear396531>
I'm building a HOST tool.
<fuzzybear396531>
--sysroot is present and correct.
<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)
<fuzzybear396531>
Yeah, sysroot-native has the right libc.
<fuzzybear396531>
If I LD_PRELOAD that libc then the executable runs.
<fray>
ok, so then you are down to compiler (need the YP native compiler) and the sysroot-native for your build(s)
<fuzzybear396531>
What's the YP native compiler?
<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.
<fuzzybear396531>
How can I access a dev shell?
<fray>
the key thing is (objdump can show you) what ld.so is the sysroot-native picking up?
<fuzzybear396531>
Which options should I pass to objdump?
<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
<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
<fuzzybear396531>
Nah, it only has the root-level path.
<fuzzybear396531>
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2,
<fuzzybear396531>
objdump -x didn't print that path... Weird.
<fray>
ok.. so if you get an interpreter of /lib/ld-linux then either the linker or compiler was wrong.
<fray>
OR the ldflags were wrong..
<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
<fuzzybear396531>
Okay, this is great to know. Thanks a lot.
<fuzzybear396531>
How can I enter a dev shell, though?
<fuzzybear396531>
That sounds really useful.
<fuzzybear396531>
Can I run do_compile from there?
<fray>
it's that last -Wl,--dynamic-linker that sets the values
<fuzzybear396531>
rburton for sure, but it's a little long.
<fray>
so if LDFLAGS isn't being handled, you won't get the right link
<fuzzybear396531>
fray Thanks a lot!
<rburton>
fuzzybear396531: just the lines that builds that tool should be fine
alessioigor has quit [Quit: alessioigor]
<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='
PhoenixMage has quit [Ping timeout: 260 seconds]
<fuzzybear396531>
For sure. Even that is a bit long, though.
alessioigor has joined #yocto
<fray>
for devshell.. bitbake -c devshell <your recipe>
<fuzzybear396531>
fray I've been living in bitbake -e all day (but mostly looking at CFLAGS). This is really helpful.
<fuzzybear396531>
fray Thanks!
<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
alessioigor has quit [Client Quit]
PhoenixMage has joined #yocto
<fray>
hopefully this can help unblock you
<fuzzybear396531>
rburton it branches based on the presence of HOST_CC versus CC so it looks a little funky:
<rburton>
fuzzybear396531: that's using target flags not BUILD_
<fuzzybear396531>
rburton I'm sorry. I don't understand.
<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
<fray>
The recipe will DEFAULT to 'target' style.. When you inherit 'native', it switching LDFLAGS (and CFLAGS) to use the "BUILD"/host versions
<rburton>
that is definitely using LDFLAGS (as it passes --sysroot)
<fuzzybear396531>
Ohhhhh
<rburton>
well, --sysroot implies CC not BUILD_CC
<rburton>
i'm presuming this is a target recipe that needs to build a single binary to run on the host
<fray>
rburton, ya I missed that.. you are right
<fuzzybear396531>
rburton Yeah, exactly.
<rburton>
the makefile needs to be cross-aware and know how to use a different compiler for host binaries vs target binaries
<fuzzybear396531>
rburton Okay, so the best thing to do would be to swap CC for BUILD_CC, here?
<fuzzybear396531>
And LDFLAGS for BUILD_LDFLAGS, etc.?
<rburton>
is this plain makefiles or autotools or what?
<fray>
that swap happens on the YP side of things.. (or should)
<fuzzybear396531>
rburton It's a plain makefile.
<fray>
the makefile should just use CC, CFLAGS, LDFLAGS, etc. (unless it's a cross compiler)
<fray>
then it's up to the recipe logic to switch the value of 'CC" from the target version to the 'native' version
<rburton>
the one rule that generates this binary should use CC_FOR_BUILD instead of CC. CC_FOR_BUILD can default to CC
PhoenixMage has quit [Ping timeout: 268 seconds]
<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)
<fuzzybear396531>
fray It does use CC, CFLAGS, LDFLAGS, etc. unless HOST_CC is present.
<fuzzybear396531>
That's how the target's Makefile logic is expressed.
<rburton>
actually BUILD_CC is exported, so use that name and it just works
<fray>
ok
<fuzzybear396531>
rburton Okay, I'll swap out the CC stuff for BUILD_CC stuff.
<rburton>
there's a trick you can do with make
<fuzzybear396531>
rburton give me all the tricks!
PhoenixMage has joined #yocto
<rburton>
iirc, mybinary: CC=${BUILD_CC}
<rburton>
where mybinary is the target for your binary
<rburton>
repeat for CFLAGS etc
<fuzzybear396531>
On new lines or comma-separated?
<rburton>
you're just overriding the variables for a specific target
<fuzzybear396531>
Yeah, and it avoids overwriting all the logic below the target.
<rburton>
especially as you've written a good makefile which doesn't have a %o:%.c rule, right? :)
<rburton>
i'll also point out here that make is terrible, use something like meson: it's better and handles stuff like this transparently
PhoenixMage has quit [Ping timeout: 248 seconds]
vmeson has joined #yocto
PhoenixMage has joined #yocto
<fuzzybear396531>
Well, so I didn't write this Makefile.
alessioigor has joined #yocto
<fuzzybear396531>
But, even then I don't know if %o:%.c is good.....
<fuzzybear396531>
Meson handles using the "right" compilers and linkers for build/target machine transparently, you mean?
alessioigor has quit [Client Quit]
<rburton>
yes
<rburton>
you just say native:true
<fuzzybear396531>
Oh, I see.
alessioigor has joined #yocto
<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.
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
leon-anavi has quit [Quit: Leaving]
ptsneves has quit [Ping timeout: 250 seconds]
amitk has joined #yocto
goliath has quit [Quit: SIGSEGV]
seninha has joined #yocto
Guest12 has joined #yocto
Guest12 has quit [Client Quit]
fuzzybear396531 has quit [Quit: Ping timeout (120 seconds)]
dallas_bruno[m] has quit [Quit: User was banned]
amitk has quit [Ping timeout: 265 seconds]
goliath has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
rcw has joined #yocto
grma has joined #yocto
cmd has quit [Remote host closed the connection]
rcw has quit [Quit: Leaving]
Mamta_ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
odra_ has quit [Ping timeout: 268 seconds]
<fray>
package manager solutions, IMHO, are only useful for larger devices. OS Tree, image based, etc are much better for embedded systems
<fray>
BUT package managers provide a ton of metadata that can be used to drive the other systems
<fray>
well remember layers/recipe extensions are designed into teh system so they can be added AFTER the initial build/release as updates...
<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
kanavin has quit [Ping timeout: 268 seconds]
fuzzybear396517 has joined #yocto
xmn has quit [Ping timeout: 244 seconds]
<LetoThe2nd>
yo dudX
alessioigor has quit [Quit: alessioigor]
<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..
<fray>
oops
<LetoThe2nd>
fray: now you just have to tell us which of the components runs YOEP
<fray>
alas none of them.. the security cam and APs are ubiquity.. so they're running Linux, but it's some debian based thing
mvlad has quit [Remote host closed the connection]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
DvorkinDmitry has quit [Remote host closed the connection]
kanavin has joined #yocto
odra_ has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
fuzzybear396517 has quit [Ping timeout: 252 seconds]
Mamta_ has quit [Quit: Connection closed for inactivity]
falk0n[m] has joined #yocto
sef has joined #yocto
florian_kc is now known as florian
sef has quit [Quit: Client closed]
odra_ has quit [Remote host closed the connection]
odra_ has joined #yocto
odra__ has joined #yocto
odra_ has quit [Remote host closed the connection]
rabbi[11] has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
florian has quit [Ping timeout: 260 seconds]
xmn has quit [Quit: xmn]
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<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.
<kergoth>
should really add an equivalent to gitconfig for aliases..
<kergoth>
need to scrap most of bbcmd.py, its subclass of Tinfoil isn't needed and is mostly broken anyway
goliath has quit [Quit: SIGSEGV]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
ak77_ has quit [Ping timeout: 268 seconds]
ak77 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]