On 12/2/21 00:11, Richard Purdie wrote:
> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
>> Try to make sure that the RUNTIME dynamic entry size is the same for all
>> binaries produced with the native compiler. This is necessary in order to
>> produce identical binaries when using differently sized buildpaths. I've
>> tried using only patchelf, and keeping the linker flags as they are, but
>> I am unable to produce identical binaries. Has anyone else managed to do
>> this with patchelf ? If not, maybe we can write a new tool that can handle
>> it ?
>>
>> The build-id also needs to be removed since it is calculated based on
>> the data present at link time. This includes STAGING_LIBDIR_NATIVE
>> and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
>> temporarily
>> preserved since some recipes will execute the binaries during do_install()
>> (for example python3-native). Later on these are removed in chrpath.bbclass.
>>
>> This hack is the first step for producing identical native binaries when
>> using
>> different build paths. 'zstd-native' is a working example.
>>
>> Signed-off-by: Jacob Kroon <[email protected]>
>> ---
>> meta/classes/chrpath.bbclass | 3 +++
>> meta/conf/bitbake.conf | 5 ++++-
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> I'm a little torn on this. Our other option would be to hardcoded a specific
> dummy path and then edit it later to the correct value. That may be neater
> than
> adding the padding. It will change the end binaries but hopefully only after
> they're installed so should give the same net end result more neatly?
>
Hmm not sure I follow. This patch adds a new dummy rpath entry,
"/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
other value we would like to put there. If I understand you correctly,
we could perhaps pad one of the ones we already pass
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
with spaces, like:
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
If that works that would be less intrusive I think.
> If we separate out the build-id patch we could hopefully get that piece merged
> as that shouldn't be controversial?
>
Yes, I can split it out into a separate patch.
But now that I've looked at this for a while, I've asked myself what
good does all this do ? The only optimization I can think of is that if
we rebuild a native recipes, and the sysroot component turns out the
same, then we don't need to create a new sstate cache entry. So we save
disk space, but disk space is cheap. We still need to build it. What I
would like is to have a common sstate dir for multiple build
directories. So if I build libtool-native in one build path, then at my
other build path it would just pick it up from sstate cache when I build
there. In the end, is that something that would be possible ?
Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159082):
https://lists.openembedded.org/g/openembedded-core/message/159082
Mute This Topic: https://lists.openembedded.org/mt/87415016/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
