<RP>
rpaths only apply to specific binaries which is more helpful
geoffhp has quit [Quit: Leaving]
<kroon>
RP, well we still have an ugly rpath padding that does the trick. I did ask in gcc-help@gcc.gnu.org if there was a way to set a fixed size RPATH at link time, but no good answer sofar
<RP>
kroon: we have some horrible section padding tricks to solve similar issues to do with inflating string sizes elsewhere in the sdk toolchain too
<RP>
kroon: the padding trick is ok to a point but I'm just not totally keen on it....
<RP>
kroon: we could wrap the python binary with a script wrapper setting the right LD_LIBRARY_PATH setting for use in the sysroot/source dir too
<RP>
can't decide what is worse :)
<RP>
khem: Looks like we may be able to simply delete yet another gcc patch!
<kroon>
RP, i feel like if we could get upstream gnu ld make it possible to pad rpath(and others?) up to a max size at link time, then in 5-10 years we wouldn't have this problem..
<kroon>
RP, yeah that wrapper would work for python, but then we'd need another wrapper for program x that also wants to do similar build-time testing..
<RP>
kroon: I'd hope we don't have too many of these
<RP>
but I don't know the scope
<kroon>
RP, or maybe those could be autogenerated :-D
<kroon>
nah
<kroon>
scratch that
<RP>
kroon: we could try just using the fixed length for python and my hack for the rest? See how widespread the issue is that way?
<kroon>
RP, we can patch python to skip the import test, and see how far it gets
<kroon>
RP, thats basically what you suggest right ?
<RP>
kroon: I was suggesting using the /non/exist/path for the rpath in bitbake.conf and override that to use your padded version just in the python-native case
<kroon>
RP, ah ok. yeah ill try that
<RP>
that would tell us how many places the padded version is needed (i.e. how many recipes run binaries during their build)
<RP>
if python is really special, we may just find some other way there. If this is widespread we'd have to go another way
* kroon
nods
wenwuZhang has joined #yocto
kroon has quit [Quit: Leaving]
Wulf has quit [Ping timeout: 252 seconds]
wenwuZhang has quit [Remote host closed the connection]
Wulf has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
wenwuZhang has joined #yocto
wenwuZhang has quit [Remote host closed the connection]
wenwuZhang has quit [Remote host closed the connection]
troth has joined #yocto
ad__ is now known as kernelspace
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
troth has quit [Ping timeout: 252 seconds]
troth has joined #yocto
troth has quit [Ping timeout: 256 seconds]
vd has quit [Ping timeout: 256 seconds]
troth has joined #yocto
ana_gasi has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Client Quit]
kanavin has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
kanavin has joined #yocto
<RP>
khem: somehow that gcc patch removal breaks mip64 and ppc only on c++ compile on target. Will have to look into it
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
camus has quit [Quit: camus]
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
kroon has joined #yocto
<kroon>
RP, another thing that i noticed was that my native sysroot-components/x86_64/ contains a lot of .a files. although we have the ar intercept now, it might be worth just disabling them in order to save some build time ? there is no point in having .a for the native libraries I suppose ?
<kroon>
RP, (I do use no-static-libs.inc)
<kroon>
RP, in fact, maybe no-static-libs.inc needs some updating
<RP>
kroon: those are meant to be disabled
goliath has joined #yocto
xmn has joined #yocto
<dvorkindmitry>
I am using systemd in my images. But busybox-syslog is installed anyway. I am disabling it as service, but is there good way not to install it if I'm using systemd?
wenwuZhang has joined #yocto
wenwuZhang has quit [Ping timeout: 256 seconds]
wenwuZhang has joined #yocto
jpuhlman_ has joined #yocto
wenwuZhang has quit [Ping timeout: 252 seconds]
maoti__ has quit [Ping timeout: 252 seconds]
camus has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
<jonmason>
RP: question regarding check-layers. Is it acceptable to reference another README in a layer's README (as we do in meta-arm, referring to a common README)?
<jonmason>
If so, I have a patch coming that might resolve the new breaking on meta-arm's check-layer breakage :)
<Wulf>
Hello. I'm looking for a single board computer (including a casing) based on i.MX6 or i.MX8 and with HDMI output and ethernet (two ports preferred). Any suggestions?
<RP>
jonmason: yes, that would seem reasonable
<RP>
jonmason: Looks like we need to tweak some testing as we didn't see those in pre merge testing :(
<jonmason>
RP: the checks look mostly sane (though the "patch" one is a little annoying)
<RP>
jonmason: I'll accept improvements, I'd not have merged had I known about the failures :/
<jonmason>
RP: no worries. I'll get something out in a little bit. I have something now, but it's a little hacky
sakoman has joined #yocto
* RP
is running out of space on his build machines and doesn't know where it has gone
<jonmason>
RP: I had to order some more hdisks on black friday for that same reason :)
<jonmason>
8TB seems to be the sweet spot on price
florian_kc has joined #yocto
<RP>
jonmason: I think I may need to do some shopping like that
<RP>
hmm, 186GB of "sources" alone
vd has joined #yocto
<jonmason>
my nas is already at 3.2TB
<jonmason>
and its just sstate, dl_dir, and nightly backups of my homedir (that get purged weekly)
<RP>
jonmason: I'd not dare look at mine, this is just the build machine
<RP>
jonmason: this sources dir has things from 15 years ago
<jonmason>
I has the sstate on my nas so my builders can share it
<RP>
jonmason: I just share it off my main builder
<jonmason>
oh, I have SDK sources from my Broadcom stuff
<jonmason>
and they're even yocto, but never upstreamed
<jonmason>
because "it's too much work"
* jonmason
wants to rant more, but decides against it
<RP>
These sources would match openzaurus and so on
* RP
is starting to think this gcc patch is deep black magic
florian_kc has quit [Ping timeout: 252 seconds]
<jonmason>
all gcc is black magic
<jonmason>
and I'm happy with it being a black box
zenstoic has joined #yocto
Bossman46 has joined #yocto
<RP>
jonmason: I wish I could do that :)
<jonmason>
looking at those tune files was the most I ever had to look into gcc and it was enough for me
<jonmason>
lots of A is actually B under the covers
<RP>
jonmason: I do need to ask you about that cortex tune change Khem was looking at, not sure I like the nocrypto variant :/
<RP>
jonmason: but not now, need food
<jonmason>
Yes, Ross asked me to look and knew it would be more than a 5 min
<jonmason>
I thought crypto was there for everything. Need to look at source again
<jonmason>
but its a moderately warm day today. so after this patch to fix check-layers, I'm doing yard work
kanavin has quit [Remote host closed the connection]
<jaskij[m]>
Question is, even if allowed by ARM, are those non-standard combinations of interest to Yocto
<jaskij[m]>
(was surprised myself when learning of this)
<jaskij[m]>
on similar note, GCC won't use NEON on v7 without `-funsafe-math`
florian_kc has joined #yocto
<jonmason>
That's fair question
<jonmason>
I'm fully convinced that this entire thing needs to be rewritten to be modular
<jonmason>
But it would take a while
maoti__ has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` has joined #yocto
kroon_ has joined #yocto
chep` is now known as chep
pabigot has quit [Ping timeout: 256 seconds]
jpuhlman_ has quit [Ping timeout: 256 seconds]
kroon has quit [Ping timeout: 256 seconds]
troth has quit [Ping timeout: 256 seconds]
zeddii has quit [Ping timeout: 256 seconds]
zeddii has joined #yocto
pabigot has joined #yocto
troth has joined #yocto
aboss has joined #yocto
aboss has quit [Client Quit]
<JPEW>
moto-timo: I added you as a maintainer on meta-phosh. Here's the first PR you can review: https://github.com/JPEWdev/meta-phosh/pull/26 ;) Just add the "gate" label after CR and Zuul should take care of the rest
otavio has joined #yocto
<moto-timo>
JPEW: taking a rest today, but ack
<JPEW>
moto-timo: no worries. Have a good day!
<kroon_>
RP, if I set phony rpaths in BUILD_LDFLAGS its only python3-native and the kernel that breaks, at least for the images I build
kroon_ has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 252 seconds]
<jaskij[m]>
<jonmason> "I'm fully convinced that this..." <- Up until fairly recently I've been using Dunfell and my machine files included `TUNE_PKGARCH = "${DEFAULTTUNE}"` because all v8 tunes set `TUNE_PKGARCH` to something like `armv8`
<jaskij[m]>
one thing, iirc crypto implies crc, so that's one combination less
<jaskij[m]>
GCC has six different tune flags for v8-a alone. 8.1 has five (seems crc became mandatory, or bundled with crypto), 8.2 and 8.3 have **ten**, which is the most. (when counting I tried to bundle together yes/no variants like `+crypto` and `+nocrypto`).
<jonmason>
Can't parse the error on my phone. I'll take a look tomorrow
<RP>
jonmason: it is a rebuild issue, for some reason gcc-runtime is rebuilding in the same directory due to the config differing but the directory not. I saw it elsewhere in the build for init system switches which is expected but I'd not have expected it for meta-arm