qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
djs has joined #yocto
piwakawaka has joined #yocto
<piwakawaka>
Hi - this is not something I've been able to find via searching, so maybe someone has some experience with this, or can suggest a similar recipe that does the same thing? The issue is that I have a third-party recipe that _deploys_ a file (i.e. the file ends up in /tmp/deploy/images/.../) and it also inherits the nopackages class, so there's no
<piwakawaka>
packages created. I want to add this deployed file to my rootfs image - i.e. "install" from the deployment location, and have all the bitbake dependencies correct for the right build ordering. I can't create a .bbappend to define do_install_append() because of the nopackages class in the original .bb recipe. Does anyone know if it's possible for a
<piwakawaka>
new recipe to install a _deployed_ file into a package? Can do_install(_append) use `install${DEPLOYDIR} ...`? If so, how do I make sure the original recipe is built (i.e. deployed) first? Do any famous examples exist?
<piwakawaka>
Hi - this is not something I've been able to find via searching, so maybe someone has some experience with this, or can suggest a similar recipe that does the same thing? The issue is that I have a third-party recipe that _deploys_ a file (i.e. the file ends up in /tmp/deploy/images/.../) and it also inherits the nopackages class, so there are no
<piwakawaka>
packages created. I want to add this deployed file to my rootfs image - i.e. "install" from the deployment location, and have all the bitbake dependencies correct for the right build ordering. I can't create a .bbappend to define do_install_append() because of the nopackages class in the original .bb recipe. Does anyone know if it's possible for a
<piwakawaka>
new recipe to install a _deployed_ file into a package? Can do_install(_append) use `install ${DEPLOYDIR} ...`? If so, how do I make sure the original recipe is built (i.e. deployed) first? Do any famous examples exist?
<piwakawaka>
sorry for the dup - thought I was editing the previous comment
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
MrBIOS- has quit [Remote host closed the connection]
camus has joined #yocto
sakoman has quit [Quit: Leaving.]
Tokamak_ has quit [Ping timeout: 248 seconds]
nemik_ has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 268 seconds]
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik_ has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
xmn has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #yocto
amitk has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
gordea has quit [Quit: gordea]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
rcw has joined #yocto
RobW has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 264 seconds]
nemik_ has quit [Ping timeout: 260 seconds]
<vvn>
RP: the /lib symlink hack didn't work, but setting MACHINE_FEATURES_BACKFILL_CONSIDERED="qemu-usermode" works around this and successfully compiles glib (pull in by systemd) with musl and usrmerge on kirkstone. Not sure whether it's a bug or not and if we should warn against this machine feature from the musl recipe?
nemik has joined #yocto
nemik_ has joined #yocto
amitk has joined #yocto
amitk_ has joined #yocto
tomzy_0 has joined #yocto
tor has joined #yocto
zpfvo has joined #yocto
rstreif has quit [Ping timeout: 260 seconds]
thomasd13 has joined #yocto
<thomasd13>
Good morning guys. I have a little problem with my cross-debugger (gdb) built by yocto: When I try to execute it, it says: error while loading shared libraries: libncursesw.so.5: cannot open shared object file
<thomasd13>
But the shared library "libncursesw.so.5" is installed. And if I'm doing an "ldd gdb" it also gets listed by its full path
<thomasd13>
I've moved from Lubuntu 18.04 to 22.04. At 18.04 it just worked as expected. Has anyone an idea whats wrong here?
<thomasd13>
Found the issue! Strace helped me out :)
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
rob_w_ has quit [Client Quit]
zpfvo has joined #yocto
rob_w_ has joined #yocto
rob_w has joined #yocto
rob_w_ has quit [Client Quit]
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
camus has joined #yocto
lexano has joined #yocto
thomasd13 has quit [Remote host closed the connection]
thomasd13 has joined #yocto
djs has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
GNUmoon has joined #yocto
KanjiMonster has quit [Ping timeout: 260 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
pbergin has joined #yocto
<LetoThe2nd>
yo dudX
leon-anavi has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
alessioigor has joined #yocto
manuel1985 has joined #yocto
<thomasd13>
I've got a problem here which I cannot solve. After installing the "arago-2021.09-aarch64-linux-sdk.sh", I cannot execute aarch64-none-linux-gnu-gdb. It fails, because it cannot find the libncursesw.so.5
<thomasd13>
The wird thing is, that it apparently searches in "/tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyy...." paths for it
<thomasd13>
This path shows also up in the post-relocate-setup.sh. Does anyone knows more about it?
gho has joined #yocto
Payam has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has joined #yocto
<pasherring>
thomasd13, dumb question, but, are you sourcing the sdk env file before running gdb?
nemik_ has quit [Ping timeout: 265 seconds]
<chrysh>
can you guys recommend platforms with three MIPI interfaces, where 3 cameras can stream in parallel for an industrial application? We are currently using an NVIDIA TX2 platform (with one camera attached over USB), but am now thinking where to go from here.
nemik_ has joined #yocto
<thomasd13>
pasherring, when I do it, the error occurs, when I am not doing it also the error occurs
<thomasd13>
At 18.04 I dont have to source the env file to execute the gdb successfully
<pasherring>
thomasd13, ah, now I read through all of your messages. Ubuntu 22 is incompatible with 18 (and 20 for that matter), due to glibc IIRC. So, most of the system libraries won't work, because most of them link against glibc.
tleb has joined #yocto
<thomasd13>
pasherring, wait what??
<pasherring>
So, you basically, have to build again the SDK for the newer distro. Or run from inside some container.
<thomasd13>
so I would also need to upgrade the yocto buildserver to ubuntu 22, to build an sdk which runs on a ubuntu 22 machine?
<pasherring>
Yes. But, also keep in mind that by doing so, some of the recipes may break
<pasherring>
Well, not exactly the recipe, but, the compile-build cycle.
<thomasd13>
pasherring, do you have any link or more details about the incompatibility of 22.04 against 20/18 ? I would like to understand this in greater detail
<pasherring>
thomasd13, yeah, about that... hehehehe I am trying to find the reference, but, so far, could find. I am keeping this in a IIRC basis.
<thomasd13>
I thought using 22.04 (LTS) is fine, since its listed at the Supported Linux Distribuations in the yocto manual
gho has joined #yocto
d-s-e has joined #yocto
<pasherring>
I think there was some breakage in glibc headers. Some stack related symbol. But, I can't clearly remember. My solution at that time was to accept defeat and roll back to 20.04
<thomasd13>
omg. I just spend 3 days to setup my new 22.04 dev-machine
<thomasd13>
So this error will apply to everything, which is built by yocto and will executed on a development machine which does not run ubuntu 22.04 ?
<thomasd13>
pasherring, thanks, i will work through that
<pasherring>
thomasd13, Not sure about how the issue manifests itself, so, I have no idea how this could affect the several packages built. I'd say that whenever a package would use the symbol SIGSTKSZ, I'd expect this to break. But, this is fairly low level interface, and I'd expect lower level packages - such as gdb - to become problematic.
florian has joined #yocto
gho has quit [Quit: Leaving.]
gho has joined #yocto
<RP>
vvn: that will have just pushed some work onto target at first boot or disabled introspection
tomzy_0 has quit [Quit: Client closed]
gho has quit [Quit: Leaving.]
gho has joined #yocto
mschnelte has quit [Quit: Client closed]
<thomasd13>
Im still fighting with the yocto-sdk. The yocto-sdk installer runs without any error message. Trying to executing the aarch64-none-linux-gnu-gdb with strace: https://dpaste.org/5xmr8
<thomasd13>
For some reason, it tries to find a particular .so in /temp/xxxxxxx..../yyyyyyyy... I know this path gets replaced during the SDK installer process with the actual install directory as a post step.
<thomasd13>
But why does it not work at (l)ubuntu 22.04 ? I just tested it on a fresh/plain image
<rburton>
xcm_: that recipe is not pretty. try just making a new recipe that just does inherit cmake
michalkotyla has joined #yocto
Kleist has joined #yocto
<RP>
thomasd13: there are some elf sections we do string replacements on at install time so I'd guess that hasn't happened there?
<thomasd13>
RP, is there any way i can debug this here? Why the hell should that work not anymore at 22.04 ?
<RP>
thomasd13: I think you probably need to put some debugging around the sdk installer and find out if/where something is failing to run or failing to make the changes needed
<thomasd13>
I mean it just not realistic, that I am the first person who observers this kind of problem??
michalkotyla has quit [Remote host closed the connection]
<rburton>
vvn: file a bug re the musl/glib thing please
<RP>
thomasd13: we have 22.04 autobuilder workers and we run sdk and esdk tests on them FWIW
<thomasd13>
RP, did you test an yocto-sdk-installer built on 18.04 on a 22.04 machine?
michalkotyla has joined #yocto
<RP>
thomasd13: scripts/relocate_sdk.py is one of the key things we use to relocate the binaries so you can get some of these scripts outside the sdk to be able to see what they're doing
<RP>
thomasd13: no, that wouldn't be tested
<RP>
but reproducible builds means the two sdks should be the same. If they're not, that is a bug
<thomasd13>
okay.. relocate_sdk.py gets deleted after the installer has finished. I will search this script somewhere else :)
<RP>
thomasd13: it is meta/scripts in oe-core
<thomasd13>
thanks a lot RP
<RP>
thomasd13: getting the arguments and steps right is tricky which is why I'd suggest hacking an installer to print the commands it runs
<aleksandarsimono>
vvn I tried what you told me to do yesterday (added RPI_KERNEL_DEVICETREEOVERLAYS:append = "overlays/mcp2515-can2.dtbo") and got do_compile() error while compiling kernel
d-s-e has quit [Ping timeout: 255 seconds]
<aleksandarsimono>
From which I conclude this is custom dtbo
neil499 has joined #yocto
x2s has left #yocto [WeeChat 2.8]
mschnelte has joined #yocto
neil499 has quit [Ping timeout: 260 seconds]
<mschnelte>
Hi. I have setup a shared bitbake-hashserv that is read-only for clients but can be written to from the build agents. Stupid me has forgotten to set BB_HASHSERVE to "host:port" of this hashserver. I did only set the upsteam server. Now my looooong time build has finished, i have a nice sstate and hashserver database on the build agent, but not on
<mschnelte>
the shared hashserver. How can i export the data? Now that I have corrected the BB_HASHSERVE="<host:port>" will a rebuild from sstate do the job? I would really try to avoid to rebuild without sstate just to repopulate the hashserver.
<mschnelte>
or can i just copy the files from tmp/cache over to the hashserver?
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
rber|res has quit [Ping timeout: 264 seconds]
vvmeson has joined #yocto
<RP>
mschnelte: there is a database file in cache/ (not tmp.cache)
jkrueger has joined #yocto
michalkotyla has quit [Quit: Connection closed]
fvincenzo has joined #yocto
lukas has joined #yocto
vvmeson has quit [Client Quit]
vvmeson has joined #yocto
piwakawaka has quit [Quit: Client closed]
Payam has quit [Quit: Client closed]
vvmeson has quit [Client Quit]
vvmeson has joined #yocto
<mschnelte>
RP: hashserv.db, right? I have copied that file over to the hashserver. I have started the server with --log DEBUG and when I start the build on the client , i see a "Client connected" message. Immediately followed by a client disconnect. But I have 0 matches. I would have expected to see several requests for hashes to the bitbake-hashserver? How
<mschnelte>
can i debug that better?
rber|res has joined #yocto
<RP>
mschnelte: yes, that is the right file. the build will cache things locally so it depends what you tried really
d-s-e has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 260 seconds]
neil499 has joined #yocto
neil499 has quit [Ping timeout: 260 seconds]
<mschnelte>
Here is what I did to debug: On the build agent I set SSTATE_DIR in order to make sure it needs to contact the SSTATE_MIRROR. I then ran bitbake core-image-minimal.
<mschnelte>
The result: Sstate summary: Wanted 547 Local 0 Mirrors 544 Missed 3 Current 808 (99% match, 99% complete).
<mschnelte>
That should show that the SSTATE_MIRROR works correctly, right?
<mschnelte>
On the client side with the same SSTATE_MIRROR I get 0 hits. So I supsect sth is throwing my hashes of. Is there a way to get the hash of one task on both side and compare them?
<mschnelte>
typo* On the build agent I set SSTATE_DIR to an empty directory in order to make sure it needs to contact the SSTATE_MIRROR
jkrueger has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<mschnelte>
Another question: Does the bitbake-hashserver only to "browse" the key/value pairs? Or is the api only allowing for "request key -> get value" calls? I.e. the hashserver can be put to the public internet without the risk of revealing which hashes are on the sstate server?
vvmeson has quit [Quit: Client closed]
<RP>
mschnelte: bitbake -g will write a locked-sigs.inc file which has all the hashes in
<RP>
mschnelte: sorry, bitbake <target> -S none
<RP>
JPEW, qschulz: Following our discussion yesterday, I wondered if we should try a multiprocessing Manager to replace the remaining use of persist_data in the fetcher
xmn has joined #yocto
<JPEW>
Ya, maybe worth looking at
kanavin_ has quit [Remote host closed the connection]
kanavin has joined #yocto
sakoman has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
davidinux has quit [Quit: WeeChat 3.5]
vvmeson has joined #yocto
d-s-e has joined #yocto
alessioigor has quit [Quit: alessioigor]
thomasd13 has quit [Ping timeout: 252 seconds]
<mschnelte>
RP: tnx for the hint. I digged and here is for example a hash difference: hash for dependent task virtual:native:..build/../poky/meta/recipes-extended/xz/xz_5.2.6.bb:do_populate_sysroot is 5e6422a75d41cfcda806cf9b009108f29a498184738f28c9cd8a88fcd9bf2e1e which is different on the other machine. They have different Ubuntu versions installed. Is this
<mschnelte>
the cause? If so what to do to prevent this? should i best run the builds in a container based upon the same image?
Qorin has joined #yocto
Net147 has quit [Ping timeout: 264 seconds]
vvmeson has quit [Quit: Client closed]
<RP>
mschnelte: no, it shouldn't be the distro
fvincenzo has quit [Quit: Client closed]
fvincenzo has joined #yocto
<mschnelte>
Hmm, this hash difference is on gcc-source. I am trying to drill down till i have no more dependent tasks by using bitbake-dumpsig. E.g. the sig of binutils-cross_2.38.bb:do_populate_sysroot is different but when i call bitbake-dumpsig -t binutils-cross populate_sysroot to follow up on that. i get "ERROR: No sigdata files found matching
<mschnelte>
binutils-cross do_populate_sysroot". Do i need to do that different?
<RP>
mschnelte: gcc-source's stamp directory is somewhere different so you can probably manually get further if you know that
<RP>
(in workdir-shared)
lukas has joined #yocto
<xcm_>
hello. i notice uboot has a default env somehow, which includes bootdelay=2. i need to change that at image build time. how can i append to this file?
prabhakarlad has quit [Quit: Client closed]
<abelloni>
smurray: meta-agl is failing check-layer-nightly on langdale because of meta-pipewire:
camus has quit [Remote host closed the connection]
prabhakarlad has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
rstreif has joined #yocto
aleksandarsimono has quit [Quit: Client closed]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
kmaincent[m] has joined #yocto
alimon has quit [Remote host closed the connection]
alimon has joined #yocto
florian_kc has joined #yocto
prabhakarlad has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 265 seconds]
<mschnelte>
For the record I solved my problem. In the end it still had to do with the hashserver. After I fixed the hashserver misconfiguration I did not delete the database of the local hashserver which was then still filled with data that was not in line with the upstream. I deleted the build directory and run the build again. This time with 99% sstate
<mschnelte>
matches.
<mschnelte>
This was a lost day - well at least I learned sth ;D
<mschnelte>
RP: Tnx for the pointers!
rstreif has quit [Read error: Connection reset by peer]
<vvn>
Wouldn't it make more sense to build the kernel in a multiconfig (to use a different initramfs distro) rather than building the initramfs in a multiconfig?
<vvn>
problem is using a multiconfig for the initramfs requires to build the kernel twice, which doesn't make sense as only the kernel from the main distro is used
<vvn>
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" can't be used because the initramfs might need to embed a kernel module (which would be empty for linux-dummy)
<vvn>
Unless there is a way to make the initramfs multiconfig depend on the built kernel instead of rebuilding it itself?
d-s-e has quit [Quit: Konversation terminated!]
fvincenzo has quit [Quit: Client closed]
gho has quit [Quit: Leaving.]
mschnelte has quit [Quit: Client closed]
gho has joined #yocto
fvincenzo has joined #yocto
kpo has joined #yocto
mschnelte has joined #yocto
mschnelte has quit [Client Quit]
gho has quit [Client Quit]
zpfvo has quit [Ping timeout: 268 seconds]
prabhakarlad has joined #yocto
zpfvo has joined #yocto
kpo has quit [Read error: Connection reset by peer]
zpfvo has quit [Client Quit]
GNUmoon has quit [Ping timeout: 255 seconds]
kpo has joined #yocto
nemik has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 260 seconds]
esben[m] has quit [Quit: Bridge terminating on SIGTERM]
Salamandar has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
lrusak[m] has quit [Quit: Bridge terminating on SIGTERM]
mrybczyn[m] has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
aleblanc[m] has quit [Quit: Bridge terminating on SIGTERM]
matiop6[m] has quit [Quit: Bridge terminating on SIGTERM]
jclsn[m] has quit [Quit: Bridge terminating on SIGTERM]
cperon has quit [Quit: Bridge terminating on SIGTERM]
Theo[m] has quit [Quit: Bridge terminating on SIGTERM]
Mickal[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
tokamak[m] has quit [Quit: Bridge terminating on SIGTERM]
phako[m] has quit [Quit: Bridge terminating on SIGTERM]
kmaincent[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
FredericOuellet[ has quit [Quit: Bridge terminating on SIGTERM]
gstinocher[m] has quit [Quit: Bridge terminating on SIGTERM]
mborzecki has quit [Quit: Bridge terminating on SIGTERM]
fmartinsons[m] has quit [Quit: Bridge terminating on SIGTERM]
ThomasRoos[m] has quit [Quit: Bridge terminating on SIGTERM]
jkorsnes[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
styloge[m] has quit [Quit: Bridge terminating on SIGTERM]
ramacassis[m] has quit [Quit: Bridge terminating on SIGTERM]
danielt has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
EwelusiaGsiorek[ has quit [Quit: Bridge terminating on SIGTERM]
zyga[m] has quit [Quit: Bridge terminating on SIGTERM]
Peter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
jackos888[m] has quit [Quit: Bridge terminating on SIGTERM]
glgspg[m] has quit [Quit: Bridge terminating on SIGTERM]
mckoan is now known as mckoan|away
demirok has joined #yocto
tor has quit [Quit: Leaving]
khem has joined #yocto
Andrew20 has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
Andrew20 has joined #yocto
zyga[m] has joined #yocto
manuel1985 has quit [Ping timeout: 248 seconds]
manuel_ has quit [Ping timeout: 265 seconds]
shoragan[m] has joined #yocto
barath has joined #yocto
Tartarus has joined #yocto
ericson2314 has joined #yocto
hmw[m] has joined #yocto
Saur[m] has joined #yocto
lrusak[m] has joined #yocto
mborzecki has joined #yocto
T_UNIX[m] has joined #yocto
PascalBach[m] has joined #yocto
gstinocher[m] has joined #yocto
esben[m] has joined #yocto
jclsn[m] has joined #yocto
phako[m] has joined #yocto
berton[m] has joined #yocto
ejoerns[m] has joined #yocto
ThomasRoos[m] has joined #yocto
johankor[m] has joined #yocto
styloge[m] has joined #yocto
FredericOuellet[ has joined #yocto
kmaincent[m] has joined #yocto
johankor[m] is now known as jkorsnes[m]
cperon has joined #yocto
matiop6[m] has joined #yocto
Mickal[m] has joined #yocto
aleblanc[m] has joined #yocto
mrybczyn[m] has joined #yocto
EwelusiaGsiorek[ has joined #yocto
fmartinsons[m] has joined #yocto
ramacassis[m] has joined #yocto
Theo[m] has joined #yocto
glgspg[m] has joined #yocto
tokamak[m] has joined #yocto
jackos888[m] has joined #yocto
agherzan has joined #yocto
kayterina[m] has joined #yocto
Peter[m]123 has joined #yocto
bahues has quit [Ping timeout: 268 seconds]
bahues has joined #yocto
Salamandar has joined #yocto
patersonc[m] has joined #yocto
danielt has joined #yocto
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
gsalazar has quit [Remote host closed the connection]
<JaMa>
"YPS Social Hour Wednesday" isn't free-to-attend, right? for those who already started to drink in expectation of promised OE Happy Hour :)
gsalazar has joined #yocto
pasherring has quit [Quit: Leaving]
bahues has quit [Ping timeout: 252 seconds]
sakoman has quit [Quit: Leaving.]
<phako[m]>
I have something escaping the sysroot here... /home/jgeorg/Projects/Yocto/plain/poky/build-kirkstone/tmp/work/cortexa57-poky-linux/mtca4u-fw-programmer/1.0+git999-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/11.3.0/ld: cannot find /lib/ld-linux-aarch64.so.1: No such file or directory - any hints on how to debug that?
<phako[m]>
:qa
<phako[m]>
I cannot express how much I hate massaging 7 years of grown cmake into something that plays nicely in a cross environment
<RP>
phako[m]: are you passing --sysroot through to the compiler/linker or is something filtering the flags?
<phako[m]>
yeah. the linker flags look ok apart from some weird rpath that is passed into
<RP>
JaMa: not sure, I think you need to ask the conference organisers or denix
<JaMa>
ack, it's not just for me (as I don't mind drinking without company :)), but I've recommended few people today (based on e-mail from denix yesterday) just before it got postponed to Friday