ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
seninha has quit [Ping timeout: 265 seconds]
seninha has joined #yocto
amitk has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
sakoman has joined #yocto
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #yocto
seninha has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
beneth has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jclsn has quit [Quit: WeeChat 3.6]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w has joined #yocto
mrnuke has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
mrnuke has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GreatGatsby[m] has joined #yocto
rfuentess has joined #yocto
lexano has quit [Ping timeout: 268 seconds]
lexano has joined #yocto
zpfvo has joined #yocto
Habbie has quit [Ping timeout: 250 seconds]
mvlad has joined #yocto
Habbie has joined #yocto
marek has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
olani has joined #yocto
Payam has joined #yocto
prabhakarlad has joined #yocto
ptsneves has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
frieder has joined #yocto
odra__ has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
leon-anavi has joined #yocto
odra_ has quit [Ping timeout: 265 seconds]
alessioigor has quit [Quit: alessioigor]
odra_ has joined #yocto
odra__ has quit [Read error: Connection reset by peer]
<abelloni>
denix: do you plan to add a langdale branch to meta-ti soon?
cmd has quit [Ping timeout: 265 seconds]
cmd has joined #yocto
fuzzybear396580 has joined #yocto
<fuzzybear396580>
How can I obtain ${PV} in a shell function called with bb.build.exec_func ? I tried "${@bb.utils.get_referenced_vars('PV', d)}" but that didn't work.
<fuzzybear396580>
I hoped/thought I would be able to get $PV from the environment directly, but it didn't work:( .
<qschulz>
fuzzybear396580: and ${PV} does not work?
<qschulz>
(not $PV, but ${PV})
seninha has joined #yocto
<fuzzybear396580>
Hm, I did ${PV}. but I didn't think it was working because a particular branch wasn't firing.
<fuzzybear396580>
Let me pull it out of that conditional block and see if it works.
<fuzzybear396580>
Er, either the branch _was_ firing and it wasn't working or the branch _wasn't_ firing and it _may_ have been working.
<fuzzybear396580>
The branch should be firing based on my conf/local.conf, though.
goliath has joined #yocto
<qschulz>
fuzzybear396580: we need more context to help you :/
<fuzzybear396580>
qschulz Okay, that shell variable was working. But, for some reason the branch isn't firing. I've checked the package context using bitbake -e <package> and I can see that $DISTRO_FEATURES _append _has_ the value that I want but it's not actually in the final $DISTRO_FEATURES .
<fuzzybear396580>
Why isn't DISTRO_FEATURES_append being appended?
<qschulz>
fuzzybear396580: whcih version of yocto are you using?
<fuzzybear396580>
Good question. Dunfell, generally. I'm not sure how to obtain the exact version (SHA or major/minor).
starblue has quit [Ping timeout: 265 seconds]
<fuzzybear396580>
I can see the values in DISTRO_FEATURES_append in conf/local.conf but they're not being appended for some reason.
<rburton>
fuzzybear396580: is your recipe native?
<fuzzybear396580>
And, I can see them in the environment output.
<fuzzybear396580>
rburton Yeah.........
<qschulz>
fuzzybear396580: the issue lies in set native.bbclass:135 [native_virtclass_handler]
<rburton>
# set native.bbclass:135 [native_virtclass_handler]
<rburton>
# "ipv6 x11 xattr"
<rburton>
native recipes get a constrained distro features, as they're native and therefore not related to the target
<qschulz>
fuzzybear396580: seems like you also need a DISTRO_FEATURES_class-native_append
starblue has joined #yocto
<fuzzybear396580>
Oh! I had no idea.
<rburton>
you might be abusing distro features
<qschulz>
then probably don't do what I suggested :)
<Saur[m]>
Though it should be `DISTRO_FEATURES_append_class-native`.
<qschulz>
Saur[m]: pretty sure not
<Saur[m]>
Pretty sure yes. ;)
<qschulz>
Because the DISTRO_FEATURES_append would work on a DISTRO_FEATURES
<fuzzybear396580>
rburton we basically want to predicate the inclusion/configuration of some packages depending on the build configuration.
<qschulz>
here, the DISTRO_FEATURES is overridden for the class-native
<rburton>
if you definitely want this feature passed through to native, then append DISTRO_FEATURES_FILTER_NATIVE
<qschulz>
so you want to *add* to this overridden DISTRO_FEATURES, hence _class-native_append
<fuzzybear396580>
rburton we only want this feature present sometimes, depending on the build.
<fuzzybear396580>
How can I know from the above that the _append values aren't used? Because there's no `set /home/johrineh/code/outer-yocto-build/poky/build/conf/local.conf` ?
<qschulz>
Saur[m]: actually, neither will work
<qschulz>
because it's a d.setVar in an anonymous python function, so _append and whatnot are done, and then the anonymous python function is run and here the d.setVar overrides it
vladest has quit [Quit: vladest]
<qschulz>
fuzzybear396580: i'm not entirely sure you can get it from the logs
<Saur[m]>
Yeah, I forgot the implications of the Python code in native_virtclass_handler(). So ether add to DISTRO_FEATURES_NATIVE (if it is a distro feature specifically targeted for native) or add to DISTRO_FEATURES_FILTER_NATIVE.
vladest has joined #yocto
<fuzzybear396580>
qschulz "logs", here, means -e output?
<qschulz>
this is a **very** specific case you stumbled upon, d.setVar is not usually used in anonymous python functions
<qschulz>
fuzzybear396580: yes
<fuzzybear396580>
Okay, so basically you all knew this because you have a better working knowledge of recipe types and in which cases which _appends work.
<fuzzybear396580>
Got it. Thanks qschulz
<qschulz>
fuzzybear396580: i am not sure that we actually explain in the docs that d.setVar in an anonymous python function will be done after all _append, _prepend, _remove whatever is done
<qschulz>
we should for sure
<qschulz>
as for the bitbake -e output, I have no idea if and how we can improve it to explicit this situation
ptsneves has quit [Ping timeout: 246 seconds]
<qschulz>
(also, there's now a bitbake-getvar -r recipe VAR tool that should be faster than bitbake -e :) )
<fuzzybear396580>
> i am not sure that we actually explain in the docs that
<fuzzybear396580>
I may have missed it, but I didn't see it.
<fuzzybear396580>
> as for the bitbake -e output, I have no idea if and how we can improve it to explicit this situation
<fuzzybear396580>
Yeah, okay. It might not be possible. I'm not sure how you'd indicate which ones are overriding which ones because of the recipe type.
<fuzzybear396580>
bitbake-getvar -r <recipe> <var> is great! Thank you!!!
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 260 seconds]
<seninha>
Hi, recipe parsing is very slow here, it stays at 0% for like 20 mins. How can I check what it is waiting to or something
<qschulz>
seninha: bitbake -DDD flags will show the log of note level I think?
<fuzzybear396580>
qschulz Somehow it's still not working. I've checked and my conf/local.conf has the right value:
<qschulz>
in addition to your normal DISTRO_FEATURES
<qschulz>
rburton: no, _append and _append_class-native will do the same thing for class-native
kim_martial[m] has joined #yocto
<qschulz>
and since _append does not work, _append_class-native won't either
<fuzzybear396580>
qschulz Works great with DISTRO_FEATURES_FILTER_NATIVE
<qschulz>
rburton: you actually pointed to the correct things to do earlier, with the DISTRO_FEATURES_FILTER_NATIVE variable
<fuzzybear396580>
qschulz I tried DISTRO_FEATURES_FILTER_NATIVE_append but to no avail.
<fuzzybear396580>
Is that supported?
<qschulz>
fuzzybear396580: seems like it should since we have such a thing in meta/classes/distrooverrides.bbclass
<qschulz>
fuzzybear396580: didn't you forget to add the leading space by any chance?
<fuzzybear396580>
Yeah, there's a 100% chance that that happened.
ptsneves has quit [Ping timeout: 260 seconds]
seninha has quit [Quit: Leaving]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
yashraj466 has joined #yocto
ptsneves has joined #yocto
<fuzzybear396580>
How should I understand this message:
<fuzzybear396580>
WARNING: preferred version go-1.18.7 of go not available (for item go)
<fuzzybear396580>
WARNING: versions of go available: 1.14.15 1.18.7
<fuzzybear396580>
The version that you want isn't available but the version that you want is available?
<neverpanic>
No, the version you want is "go-1.18.7", the version you have is "1.18.7"
<fuzzybear396580>
Oh.....
<fuzzybear396580>
Yep. Changing from PREFERRED_VERSION_go = "go-1.18.7" to PREFERRED_VERSION_go="1.18.7" cleaned it up.
ptsneves has quit [Ping timeout: 264 seconds]
rsalveti has quit [Read error: Connection reset by peer]
jamestperk has quit [Ping timeout: 260 seconds]
rsalveti has joined #yocto
bradfa has quit [Read error: Connection reset by peer]
rburton has quit [Read error: Connection reset by peer]
bradfa has joined #yocto
rburton has joined #yocto
jamestperk has joined #yocto
ptsneves has joined #yocto
yashraj466 has quit [Quit: Client closed]
milkylainen has joined #yocto
<milkylainen>
Snapshots are disabled @ git.yoctoproject.org?
<manuel__>
Hi all! I'm building a core-image-minimal-xfce but when starting in qemu I just get a X mouse pointer on an otherwise black screen.
<manuel__>
Sometimes for the glimpse of a second I can see a window shining through.
<manuel__>
Can't see an obvious error message in /var/log/Xorg.0.log.
<manuel__>
What can I do to get a proper xfce desktop?
<manuel__>
Ok I managed to log into qemu through serial console and stopped xserver-nodm. X releases the screen and I see a few error messages that it seems to have printed on the terminal while it was shadowed by X. Is there a copy of these error messages in some log file? Don't see them in /var/log/Xorg.0.log
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
fuzzybear396580 has quit [Quit: Ping timeout (120 seconds)]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
chep has joined #yocto
zpfvo has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
<milkylainen>
snapshots @ git.yoctoproject.org is broken?
<milkylainen>
Anyone?
seninha has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
milkylainen: what do you mean by snapshots
fuzzybear396556 has joined #yocto
<fuzzybear396556>
bitbake -c devshell go isn't popping me into a devshell. Why could that be?
<fuzzybear396556>
I don't see any error output.
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<fuzzybear396556>
The last few lines that I see look like
<rburton>
it won't work long-term as the checksums could change
<milkylainen>
rburton: well. There are some other projects relying on this capability too. opkg and opkg utils are used by others too.
<milkylainen>
I mean, regardless of the checksum change or not.
<rburton>
the checksum will randomly change over time, it's a miracle it continues to work
<milkylainen>
Has worked for.. like forever?
<rburton>
the yocto mirror should have a copy of that tarball
<milkylainen>
But yeah. Absolutely a problem.
<manuel__>
I'm trying to run a core-image-minimal-xfce, but Xorg just makes the screen go black (displays a mouse cursor though) and prints this on stderr underneath the black screen. What is missing on my image? https://pastebin.com/TGL9ZhAK
seninha has quit [Ping timeout: 268 seconds]
<milkylainen>
rburton: I think snapshots stopped working like two days ago?
<rburton>
halstead: ^^^
nemik has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
seninha has joined #yocto
nemik has joined #yocto
<halstead>
rburton: milkylainen, we disabled cgit tarballs about 15 hours ago because they were causing load issues on the mirrors. I thought mindless crawlers were causing the problem not any purposeful use.
<rburton>
i'm fixing the recipes that refer to them now
<rburton>
can we enable them for specific repos?
<rburton>
i'm shocked we have recipes using them
<halstead>
rburton: we can enable tar.gz snapshots. tar.bz2 snapshots are breaking the mirrors.
<halstead>
rburton: ideally we could disable that function entirely though
<rburton>
halstead: absolutely
<rburton>
we can fix the git trees but people using old releases will still try and grab them
<halstead>
rburton: milkylainen, will tar.gz do the trick or were the tar.bz2 linked to?
<rburton>
just checked, its only .gz
<halstead>
rburton: maybe I can redirect to a static file.
zpfvo has quit [Ping timeout: 264 seconds]
<halstead>
Ok
<halstead>
This will take a few minutes
<fuzzybear396556>
I have a compile step that's failing.
<fuzzybear396556>
I tried to enter a devshell but it's not working.
<fuzzybear396556>
I don't see any error with bitbake -c devshell <package>, though.
<fuzzybear396556>
exit code 0 and statements printed indicating parsing and executing tasks.
GNUmoon has quit [Ping timeout: 258 seconds]
<fuzzybear396556>
But, when the command finishes I'm still in the same directory with the same environment (build folder with my standard shell environment).
<fuzzybear396556>
Anyone know why bitbake -c devshell <package> may not be working?
<fuzzybear396556>
devshell-15193: 1 windows (created Thu Oct 6 15:31:51 2022) [224x62] (attached)
<milkylainen>
halstead: If we can't have it as it was then gz will do for me. Dunno about other projects.
<fuzzybear396556>
Oh, no. It only spawned a new session when I wasn't already in a tmux session (when I detached).
<halstead>
milkylainen: We really can't handle generating tar.bz2 snapshots on the fly without major expense.
<milkylainen>
halstead: It's ok. gz works too.
<milkylainen>
halstead: If you wish to kill the functionality, some sort of heads up would be nice. There are a lot of various older build envs relying on this everywhere.
GNUmoon has joined #yocto
<halstead>
milkylainen: I realize that now. I incorrectly assumed no automated functionality relied on this feature,
<halstead>
tar.gz ree-nabled for openembedded. Working on yoctoproject.org.
GNUmoon has quit [Remote host closed the connection]
<milkylainen>
halstead: tnx. :) will test.
zpfvo has joined #yocto
<halstead>
milkylainen: The change is pushed. Allow 10 to 15 minutes for the gears to turn.
GNUmoon has joined #yocto
<milkylainen>
ah
<milkylainen>
Why are snapshot from tagged things provided dynamically? Sounds really taxing on the machine. I mean. Guess most snapshot fetches were tag related ones?
<rburton>
even if they're cached, they'll be reclaimed at some point
<rburton>
see the same problem with using the /archive/ links on github
<rburton>
generated and cached. then regenerated at some point, different checksum.
<fuzzybear396556>
Which tasks are executed before bitbake -c devshell <package> spawns a dev shell?
<fuzzybear396556>
Also, is there a way to get the do_compile or do_install from within the dev shell?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GNUmoon has quit [Remote host closed the connection]
kscherer has joined #yocto
<milkylainen>
halstead: opkg-utils snapshot just back too. tnx.
GNUmoon has joined #yocto
beneth has joined #yocto
zpfvo has joined #yocto
GNUmoon has quit [Remote host closed the connection]
Haxxa has quit [Ping timeout: 248 seconds]
<rburton>
fuzzybear396556: the shell tasks exist as temp/run.do_compile etc
valenvb has quit [Quit: Client closed]
<rburton>
fuzzybear396556: and as for what tasks: "addtask devshell after do_patch do_prepare_recipe_sysroot"
<halstead>
milkylainen: We'll see how the servers hold up. I'll announce on the lists if we need to discontinue snapshots with a timeframe to move to other options.
<milkylainen>
halstead: appreciated. tnx for the quick response.
GNUmoon has joined #yocto
<LetoThe2nd>
yo dudX
Haxxa has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik 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
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
seninha has quit [Read error: Connection reset by peer]
seninha has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<tperrot>
manuel__: I've been reproducing this Xfce issue for several days, and I’m trying to fix it without success for the moment.
<manuel__>
tperrot: Good to hear it's not just me
<manuel__>
But still I'm wondering... shouldnt be core-image-minimal-xfce be working and tested?
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
whuang0389 has joined #yocto
<fuzzybear396556>
rburton Thanks for the info about devshell!
<tperrot>
manuel__: me too, so I'm opening a bug.
<manuel__>
tperrot: Just posting on the mailing list
olani has quit [Ping timeout: 268 seconds]
otavio has quit [Ping timeout: 268 seconds]
otavio has joined #yocto
<manuel__>
When sending to the mailing list, is it okay to attach files 12kB in size?
Minvera has joined #yocto
<chrysh>
is there a default rule which ipks end up in the sdk and which ones in the rootfs? (e.g. per default *${PN}-dev.ipk and *${PN}.ipk would only be in the rootfs and *${PN}.ipk in sdk? or something?)
<tperrot>
manuel__: Thank you, I will indicate that I reproduce this issue.
vladest has quit [Ping timeout: 264 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
kim_martial[m] has quit [Quit: User was banned]
zpfvo has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
<rburton>
chrysh: the image recipe defines what goes into the rootfs (IMAGE_INSTALL etc). A SDK generated from the same recipe is the same package list but with dev-pkgs enabled (so for every foo in the image, foo-dev is installed). TOOLCHAIN_(HOST|TARGET)_TASK can be used to add more packages to the sdk, either host or target.
alessioigor has joined #yocto
<JaMa>
is linux-libc-headers/*.do_packagedata.* expected to depend on PRSERV_ACTIVE? this looks as a bug to me:
<JaMa>
basehash changed from 59018e7d93c51a6dc7b72cfce8b27244061d0d757dfaa80e5b61405d96728f0b to 76d86c10258519885c1d8278114125f6a395dd8283c115a997e462fed5c4f7cf
<JaMa>
Variable PRSERV_ACTIVE value changed from 'False' to 'True'
seninha has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
florian has quit [Quit: Ex-Chat]
<kergoth>
Has anyone attempted to alter our toolchain component test suites to be able to run under a generated yocto sdk environment? The current sdk tests are really bare bones, yet we run a full suite for the -cross recipes. But nothing fully tests the cross-canadian binaries, we just assume they're equivalent to -cross
<kergoth>
Guessing probably not
<fray>
Mentor/Code Sourcery had done that years ago... but no idea what happened to that code.. It was pretty simple (but not integrated into the environment)
<kergoth>
I'm building an "external toolchain" that's actually a yocto sdk which can be used by TCMODE=external-oe-sdk, but realized the testing for such a toolchain is pretty weak. We can test -cross, and that's great, and the glibc tests will make sure the shipped bits in the target sysroot are good, but we aren't really testing the functionality of the shipped cross gcc
<kergoth>
just assuming it's good if -cross is
<kergoth>
thanks, that's useful, i'll check with our toolchain folks
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
JaMa: that looks very wrong
Minvera has quit [Remote host closed the connection]
<kergoth>
Huh. meta-mingw changes target checksums by globally exporting new toolchain component variables. oops.
<kergoth>
so switching from linux to mingw sdkmachine will change everything
<kergoth>
better fix that..
dmoseley_ has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
dmoseley has quit [Ping timeout: 268 seconds]
dmoseley has joined #yocto
dmoseley has quit [Client Quit]
dmoseley has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
whuang0389 has quit [Ping timeout: 252 seconds]
odra_ is now known as lrossett
fuzzybear396556 has quit [Quit: Ping timeout (120 seconds)]
olani has joined #yocto
prabhakarlad has quit [Ping timeout: 252 seconds]
<kiwi_29_[m]>
Hello ... what is the difference between recipe-sysroot and recipe-sysroot-native ?
<kiwi_29_[m]>
I am compiling a recipe which basically compiles a go program. As part of compilation, there is also a clang compiler invoked. Now the compilation of this c program using clang is failing because clang is looking for include dirs in recipe-sysroot-native . But the asm/types.h file that it is looking is inside recipe-sysroot. I saw that the env variable CPPFLAGS_FOR_BUILD is set to "-isystem<PATH_WITH_recipe-sysroot>"
<kiwi_29_[m]>
* Hello ... what is the difference between recipe-sysroot and recipe-sysroot-native ?
<kiwi_29_[m]>
I am compiling a recipe which basically compiles a go program. As part of compilation, there is also a clang compiler invoked. Now the compilation of this c program using clang is failing because clang is looking for include dirs in recipe-sysroot-native . But the asm/types.h file that it is looking is inside recipe-sysroot. I saw that the env variable CPPFLAGS\_FOR\_BUILD is set to "-isystem\<PATH\_WITH\_recipe-sysroot-native>"
<kiwi_29_[m]>
Some way I have to either install include files inside recipe-sysroot or let the Makefile which compiles this c program as part of the recipe know that the it should also search the path containing recipe-sysroot along with all the other paths for the include file
alessioigor has quit [Quit: alessioigor]
seninha has joined #yocto
<khem>
kiwi_29_: recipe-sysroot contains the target libraries/headers and recipe-sysroot-native contains the tools/libs-needed-by-host-tools etc. basically target stuff is in recipe-sysroot
<khem>
now if you are needing to use clang, find out if its building portions which are part of target build iow installed on target, then you perhaps want to use clang based cross compiler, which you can get from meta-clang
<kiwi_29_[m]>
I am using meta-clang
<khem>
all then you need to do is add TOOLCHAIN = "clang" in your recipe and it will redirect default c/c++ compiler to use clang
<khem>
ok
<kiwi_29_[m]>
The main build is a go build
<kiwi_29_[m]>
but it also compiles a bpf code in c language using clang
<khem>
what is clang building ? is it some tool that you will need during build
<khem>
I see, then perhaps you can add TOOLCHAIN = "clang" and if you are lucky thats all you would need
<khem>
bpf stuff will be for target so you need a proper cross compiler
<kiwi_29_[m]>
I do have TOOLCHAIN="clang" in beginning of recipe
<kiwi_29_[m]>
I wonder if that is a problem ^
<khem>
good, then check your component's Makefiles and see how is it invoking it
<khem>
you mentioned its looking inside native sysroot that tells me that your package is calling bare clang and not <target-prefix>-clang as compiler
<kiwi_29_[m]>
You are right
<kiwi_29_[m]>
I just checked the third party Makefile and it is calling clang directly
<khem>
right so change it to call CC/CXX etc
nemik has quit [Ping timeout: 265 seconds]
<kiwi_29_[m]>
This is a thirdparty source...what would be proper way to make the change without changing their Makefile directly?
nemik has joined #yocto
<kiwi_29_[m]>
Is there a way to replace the Makefile before compilation starts?
<kiwi_29_[m]>
I am not able to make changes to their repo ...which means I will have to make change in the build dir
<kiwi_29_[m]>
* make change to Makefile in the, * build dir?
<khem>
you can patch it
<khem>
lot of times folks dont test their stuff in cross build environments and these things come in, you patch them and upstream them, until they make the round trip you keep the patch locallly
<kiwi_29_[m]>
cool thanks...let me try it out
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<kiwi_29_[m]>
btw..I have used the devtool in the past for patching and is extremely buggy (do not recall the exact usecase as it does many things). But do you still recommend using devtool? or manually generating the patch file and referencing inside recipe?
amitk has quit [Ping timeout: 268 seconds]
<khem>
devtool is perhaps easier if you are at yocto-fu then other methods work too
<kiwi_29_[m]>
there is some problem with the staging area that it creates..but anyway... let me try manual way first...thanks a lot
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Client Quit]
florian_kc has joined #yocto
prabhakarlad has joined #yocto
seninha has quit [Ping timeout: 268 seconds]
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 265 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
ptsneves has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
olani has quit [Ping timeout: 252 seconds]
kscherer has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
mvlad has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
justHaunted is now known as _justHaunted
_justHaunted is now known as justHaunted
florian_kc has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
dmoseley_ has quit [Ping timeout: 260 seconds]
Estrella___ has quit [Read error: Connection reset by peer]
Estrella_ 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
<kiwi_29_[m]>
khem: This is the value in CC x86_64-poky-linux-clang -target x86_64-poky-linux -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -mlittle-endian -Qunused-arguments -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=<PATH>/build/tmp/work/core2-64-poky-linux/RECIPENAME/1.0-r0/recipe-sysroot
<kiwi_29_[m]>
When compiling , I get this error "error: unknown FP unit 'sse'"
<kiwi_29_[m]>
When I remove -mfpmath=sse , then the compilation happens.
<kiwi_29_[m]>
I tested this using devshell. How can I remove -mfpmath=sse from the actual CC variable as part of recipe compilation
dmoseley has joined #yocto
dmoseley has quit [Ping timeout: 246 seconds]
roussinm has joined #yocto
<roussinm>
I'm trying to get libgles3 part of the target sdk. Even if my recipes depends on virtual/libgles3, it will not be part of the target sdk. But if the recipe depends on `virtual/libgles2` it's now part of the target sdk. virtual/libgles3 only provides header files, but still needed for our target sdk with qt. virtual/libgles3 is provided by mesa. I thought that only depending on the virtual package
<roussinm>
would pull the -dev part inside the sdk, but I guess I'm missing something here. Weird thing is, gles2 headers and so are deployed to the target sdk.
leon-anavi has quit [Remote host closed the connection]