<hummerbliss>
rburton your suggestion to use buildtools tarball worked nicely thank you. I am planning to write a buildtools.bbclass to fetch and setup buildtools tarball (similar to uninative.bbclass). Would that be a terrible idea to go that route ?
Kubu_work has joined #yocto
vmeson has quit [Ping timeout: 256 seconds]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
<RP>
hummerbliss: isn't there already a script which installs it?
<RP>
hummerbliss: scripts/install-buildtools
Guest41367 has quit [Ping timeout: 240 seconds]
dgriego has quit [Ping timeout: 250 seconds]
dgriego has joined #yocto
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
<hummerbliss>
RP indeed there is. That would mean two extra build steps (and changing dev workflow and build jobs to include additional steps). Where as buildtools.bbclass (if it can be done) would be transparent (we just have to INHERIT += buildtools in our conf files).
<RP>
hummerbliss: buildtools is used to provide python in some cases where the system one is too old so installing it in a class wouldn't work in those situations
mvlad has joined #yocto
Guest41367 has joined #yocto
<hummerbliss>
RP: ah I see, thank you
<rburton>
hummerbliss: are you having to use an old distro to build on?
pon4ik_mudrosti has joined #yocto
Guest49 has joined #yocto
ekuja3 has joined #yocto
ekuja3 has quit [Client Quit]
Guest49 is now known as ekuja3
plangowski has quit [Quit: Client closed]
<hummerbliss>
RP yup
<ekuja3>
hej
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
vmeson has joined #yocto
pon4ik_mudrosti1 has joined #yocto
Sai-Kiran has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
<Sai-Kiran>
Hi. I am trying to build rust application using Yocto. When building using bitbake, I get the following error | fatal: unable to access '<github-repo>': Could not resolve host: github.com. I tried enabling CARGO_NET_GIT_FETCH_WITH_CLI in .cargo/config in the repo. Then the source code is downloaded. But when compiling, I get the same error again.
<Sai-Kiran>
Note that the rust application has a dependency on another rust application. And in that repo also, I enabled CARGO_NET_GIT_FETCH_WITH_CLI. But I get Could not resolve host github.com. Any thoughts?
brrm has quit [Ping timeout: 248 seconds]
<neverpanic>
Network access is only enabled in the do_fetch task
<neverpanic>
cargo-bitbake can even generate a recipe template for you, I'd start with that if I were you
<Sai-Kiran>
Yes I am using the recipe generated by cargo-bitbake.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<neverpanic>
Then cargo shouldn't attempt to download sources during the build (if that's what's actually happening; your initial report didn't actually say in which phase you got the error)
OnkelUlla has quit [Remote host closed the connection]
Guest63 has quit [Quit: Client closed]
<Sai-Kiran>
neverpanic. Thanks. I am able to download. Some other errors though.....trying to fix them.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
brrm has quit [Ping timeout: 248 seconds]
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
brrm has joined #yocto
Guest41367 has joined #yocto
<Sai-Kiran>
namespaced features with the `dep:` prefix are only allowed on the nightly channel and requires the `-Z namespaced-features` flag on the command-line.
<Sai-Kiran>
Any idea on how to fix this? Googled it. But not sure how to fix this in Yocto.
Guest3 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest3 has quit [Quit: Client closed]
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
brrm has quit [Ping timeout: 256 seconds]
OnkelUlla has joined #yocto
hummerbliss has joined #yocto
brrm has joined #yocto
starblue has quit [Ping timeout: 250 seconds]
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
starblue has joined #yocto
Guest41367 has joined #yocto
ekuja3 has quit [Quit: Client closed]
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
<Scorpi>
Hi, my kirkstone SDK does not work regarding the kernel source using kernel 6.1. make modules_prepare ends up in a fork bomb. This does not happen when using kernel 5.19.
Chaser has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
hummerbliss has quit [Ping timeout: 246 seconds]
Guest41367 has quit [Remote host closed the connection]
Guest41367 has joined #yocto
Guest41367 has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
<qschulz>
has anyone managed to link qtbase from meta-qt6 (v6.5.2) against libmali in Yocto?
<qschulz>
somehow it doesn't find a symbol that is available in libmali, though libEGL.so against which qtbase links has a NEEDED on libmali and there's a -Wl,as-needed flag it seems so it should be pulled in shouldn't it?
Ablu has quit [Ping timeout: 248 seconds]
rfuentess has quit [Ping timeout: 256 seconds]
<Sai-Kiran>
Hi. Could someone let me know how to 'cargo clean' in yocto?
pon4ik_mudrosti has quit [Quit: Client closed]
pon4ik_mudrosti has joined #yocto
pon4ik_mudrosti has quit [Client Quit]
Sai-Kiran has quit [Quit: Client closed]
pabigot has joined #yocto
amitk_ has joined #yocto
amitk_ has quit [Ping timeout: 245 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
<LetoThe2nd>
Made my day: typo "contirubing"
<RP>
JPEW, rburton: patches to make PV no longer contain the SRCREVs sent
<zeddii>
yah. It was always odd to me that some threw the error, some didn't. And then unlike the kernel recipes i had a zillion (literally) git:// scms in the SRC_URI, so I picked the main one and the second one for the SRCREV_FORMAT
<RP>
zeddii: just realised it is meta-oe recipes!
* zeddii
is struggling to uprev k3s, so is in multi-scm pain at the moment.
<zeddii>
RP: indeed. but you may find meta-virt as well :)
* zeddii
stays tuned
chep has joined #yocto
<RP>
zeddii: I think these recipes just need to have it added. I have no idea how it works atm
<RP>
Actually, I do. They don't set PV to contain SRCPV which is against the guidance
tepperson has joined #yocto
<zeddii>
right! I remember coming to that conclusion once, and promptly flushed it from my mental cache
Vonter has quit [Quit: WeeChat 4.0.2]
<RP>
khem: see the above, I think meta-oe will need some missing SRCREV_FORMAT entries adding
<tepperson>
does anybody have guidance for building a python wheel with pip wheel in a recipe? I
<tepperson>
I am getting stuck where it can't find cmake
<rburton>
tepperson: cmake being involved isn't usual so you'll have to figure it out. i guess depending on cmake-native might be a useful start.
<tepperson>
rburton: I've got cmake-native in my depends already
<rburton>
tepperson: cmake being used at all tells me this isn't a standard python thing so you'll just have to look at what its trying to do and figure out how to make it work
Vonter has joined #yocto
<tepperson>
is there a trick for a python package that requires opencv-python?
<khem>
RP: thanks for noticing, are your changes on Alex's branch
<RP>
khem: not yet, just master-next
florian has quit [Quit: Ex-Chat]
<qschulz>
can anyone tell me why using --add-needed or --copy-dt-needed-entries flag for the linker would be a bad idea?
<qschulz>
because my understanding is that then if I have libA depending on libB and I only pass -lA to compile a binary, libB should also be pulled in as a dependency without actually being explicitly added as -lB
<qschulz>
and I would see this as a generally good idea
<qschulz>
especially if libA links against different libraries over its different versions but I don't care for my binary
<qschulz>
(still hunting this qt6 not linking rockchip libmali :) )
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
<qschulz>
mmmm, so if I compile **without** -Wl,--as-needed (or with -Wl,--no-as-needed) the small test snippet works...
alessioigor has quit [Client Quit]
<qschulz>
I guess something's wrong with how this libmali wrapper is written
amitk_ has joined #yocto
Vonter has quit [Ping timeout: 248 seconds]
<neverpanic>
qschulz: That typically means that no symbol from the library that is omitted is used by the binary you're linking. In weird corner cases, --as-needed can also require specifying a library twice, e.g., -lA -lB -lA
Vonter has joined #yocto
<neverpanic>
qschulz: --no-as-needed is commonly required when a library "registers" itself on load. For example if libB has a constructor that tells libA about its existance by invoking a libA function, and libA stores a function pointer in some internal table.
<neverpanic>
Such libraries can exist without ever linking against symbols from other libraries.
<qschulz>
this links to libA (libEGL.so) only but the symbol is in libB (libmali)
<qschulz>
so the symbol is needed, the linker doesn't find it if I don't explicitly pass -lmali
<qschulz>
however, libEGL.so has a NEEDED on libmali.so, so I'm getting all confused on why we always need to have dependencies of dependencies in there
kpo has joined #yocto
<khem>
qschulz: Generally these options are good to use to reduce over linking modern linkers e.g. lld have this as default
<khem>
--as-needed would intruct linker to not link in a library unless one or more non-weak symbols are referenced by an object file
shebbar has joined #yocto
<khem>
one problem I can see is a case where a program might declare symbol references as weak but then expect the library to be part of DT_NEEDED section
tgamblin has quit [Ping timeout: 245 seconds]
prabhakarlad has joined #yocto
TheJames has joined #yocto
<TheJames>
Hi all, I've been following some tutorials, and now I stumbled upon an error I cannot solve:
<TheJames>
ERROR: No recipes in default available for:
<belgianguy>
I don't get what that "default" means, does it mean it cannot handle the contents? (which seems like a patch file to me, kirkstone branch)
<neverpanic>
qschulz: Well, sounds like it's doing the right thing then, none of the symbols provided by libEGL.so are required by the program, so why would it link it?
Vonter has quit [Ping timeout: 248 seconds]
Vonter has joined #yocto
florian_kc has joined #yocto
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #yocto
dodoradio has joined #yocto
kpo has quit [Ping timeout: 245 seconds]
<dodoradio>
hi, is there a way to get a 64 bit package to build on a 32 bit system?
<dodoradio>
I've got a machine that needs a 64 bit kernel and a 32 bit packages for everything else (32 bit is needed because of some binary blobs that I can't control)
<dodoradio>
our setup is such that we really would prefer to have these all compiled as part of one machine
dodoradio has quit [Quit: dodoradio]
Vonter has quit [Ping timeout: 258 seconds]
Vonter has joined #yocto
<qschulz>
neverpanic: libEGL is what every piece of SW wanting to do EGL is going to like against
<qschulz>
it just happens that this is a mostly empty wrapper to define some functions for matching newer versions of the upstream lib and not forward the request to the actual lib that does the EGL stuff (libmali)
<khem>
belgianguy: can you add more context to your question ?
<qschulz>
so actually, I need libEGL for sure yes, because of "compatibhilty" mode but also libmali because this is the thing that actually implement everything
<khem>
Does libEGL.so have DT_SONAME ?
<khem>
sometimes precompiled solibs are piece of your know
<khem>
I mean libmali.so
kpo has joined #yocto
<qschulz>
khem: libmali's SONAME is libmali.so.1 and libEGL has a NEEDED on that exact name
<belgianguy>
khem, I am following a YT tutorial, and I've been following the explanations and steps they are doing, and on YT it builds fine, but my "bitbake core-image-minimal" fails with the above error, and I don't even understand what files it's trying to patch
<belgianguy>
As I can't see those files anywhere (or they are assumed to be on a specific location)
<belgianguy>
For now, I have deleted the gcc folder of the meta-st-stm32mp layer and am hoping for the best :/
<JaMa>
khem: qschulz: and some other prebuilt libmali.so binaries from evil BSPs ship just libmali.so with libmali.so SONAME and bunch of different symlinks to it like libEGL.so.1 and then you get bunch of file-rdeps issues from anything which links with libEGL.so.1 or you rebuild against this junk and get libmali.so in NEEDED instead of libEGL.so.1
<khem>
st layer and poky layer you are using are out of sync
<belgianguy>
ah, I had taken great care to have all kirkstone checkouts
<belgianguy>
but is there something else that I can check that would show me the "synced"-ness of my setup?
<khem>
even though they are kirkstone I guess st layer is not keeping up
<khem>
maybe use yocto-4.0.11 point release instead of latest kirkstone of poky
<belgianguy>
khem, would that be in combination with the rename, or without the rename of the .bbappend file?
<khem>
without
<belgianguy>
thx :)
<neverpanic>
qschulz: Sounds like the libEGL (or libmali) pkg-config or CMake config files should export -Wl,--push-state,--no-as-needed -lEGL -lmali --Wl,--pop-state?
goliath has quit [Quit: SIGSEGV]
<neverpanic>
helpfully, CMake will re-order those arguments, so if you want to make this CMake-proof, you'd probably need -Wl,--push-state,--no-as-needed,-lEGL,-lmali,--pop-state
prabhakarlad has quit [Quit: Client closed]
<khem>
so what is the problem with libEGL and libmali that you are trying to solve
Vonter has quit [Ping timeout: 246 seconds]
<belgianguy>
my build failed on meson, now trying withe yocto-4.0.11 release
<belgianguy>
khem, is there any literature/specific domain knowledge needed to see how synced certain layers are?
Vonter has joined #yocto
florian_kc has joined #yocto
dodoradio has joined #yocto
belgianguy has quit [Remote host closed the connection]
dodoradio has quit [Quit: dodoradio]
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
mvlad has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 256 seconds]
Chaser has quit [Quit: Chaser]
kpo has quit [Ping timeout: 248 seconds]
Crofton has quit [Ping timeout: 246 seconds]
flynn378 has quit [Ping timeout: 246 seconds]
flynn378 has joined #yocto
Crofton has joined #yocto
lexano has joined #yocto
Perflosopher has quit [Ping timeout: 248 seconds]
Perflosopher has joined #yocto
florian_kc has joined #yocto
dash_hope has joined #yocto
<dash_hope>
i am not familiar with meson build so wondering if anyone knows this:
<rburton>
dash_hope: just change your includes to be <internal/something.h>?
belgianguy has joined #yocto
<belgianguy>
is there any literature/specific domain knowledge needed to see how synced certain layers are?
<belgianguy>
I'm really new to embedded Linux, and I've faced some compilation errors out of the blue, so I could do with some pointers :)
<rburton>
What do you mean by “synced”
<rburton>
For layers it’s expected that if they’re all on the same branch it should work
<rburton>
Mixing branches is for the brave and/or foolish
<belgianguy>
rburton, I had a build following a youtube tutorial, while they all were on dunfell, I replicated their steps on kirkstone
<belgianguy>
yocto and all layers were on kirkstone, and I got a really weird error
<belgianguy>
ERROR: No recipes in default available for: /home/wietse/Documenten/Seco/MyonI/Yocto/meta-st-stm32mp/recipes-devtools/gcc/gcc-source_11.3.bbappend
<rburton>
That’s probably meta-st being out of date. Harass them.
<belgianguy>
and khem told me st was behind, and I should use the point yocto release 4.0.11
<rburton>
Yeah
<belgianguy>
But I don't have the reflexes or senses as to "why" that should be, or how to detect these issues
<rburton>
Well the bbappend specifies a version that doesn’t exist in latest kirkstone, so khem just looked at when that version did exist
<rburton>
Correct action here is to report a bug to ST
<belgianguy>
the gcc version you mean?
<rburton>
Yes
<belgianguy>
rburton, I looked at the st repo, but I saw no place to report it (no issues tab either)