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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core