[OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation

Richard Purdie richard.purdie at linuxfoundation.org
Fri Jan 11 16:53:47 UTC 2019


On Fri, 2019-01-11 at 16:49 +0000, Mike Crowe wrote:
> Until now, glibc was responsible for creating an AArch64 dynamic
> loader symlink if required for ABI compatibility.
> 
> Unfortunately, using multilib with AArch64 caused the rmdir in
> glibc-package.inc:do_poststash_install_cleanup to fail because that
> task did not expect to find the dynamic loader symlink in /lib.
> 
> Also, although glibc-package.inc:do_install_append_aarch64 made use
> of ${nonarch_base_libdir} to create the dynamic loader symlink in a
> way that was compatible with usrmerge, it unfortunately explicitly
> added only /lib to libc_baselibs, so the symlink was not packaged
> correctly when using usrmerge.
> 
> Attempting to fix both of these problems within glibc-package.inc in
> various ways created a bit of a mess. It seemed much simpler to
> invent a new package for the symlink and have glibc RDEPEND on that
> package if required.
> 
> Richard Purdie suggested[1] that ${nonarch_base_libdir} should not be
> used in this way. I've switched to using ${root_prefix}/lib which
> continues to work both with and without usrmerge.
> 
> Unfortunately, it appears not to be possible to specify the name of
> the loader via a variable with an override, since the _aarch64
> override is applied even for _aarch64-be.

I wish there was a simpler way to do this. How ugly is the patch to fix
this without adding the new recipe? Adding new recipes which are arch
specific like this is a pain for world builds and I think this patch
will have problems with those :(.

Cheers,

Richard



More information about the Openembedded-core mailing list