[v2] glibc: Separate out AArch64 multilib loader symlink creation

Submitted by Mike Crowe on Jan. 11, 2019, 4:49 p.m. | Patch ID: 157799

Details

Message ID 20190111164951.8329-1-mac@mcrowe.com
State New
Headers show

Commit Message

Mike Crowe Jan. 11, 2019, 4:49 p.m.
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.

Build-tested and inspected core-image-minimal rootfs with:

* AArch64 no multilib (real loader in correct place)
 MACHINE = "qemuarm64"

* AArch64 multilib (symlink in correct place)
 MACHINE = "qemuarm64"
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
 require conf/multilib.conf

* AArch64 usrmerge (real loader in correct place)
 DISTRO_FEATURES += "usrmerge"
 MACHINE = "qemuarm64"

* AArch64 multilib usrmerge (symlink in correct place)
 DISTRO_FEATURES += "usrmerge"
 MACHINE = "qemuarm64"
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
 require conf/multilib.conf

* AArch64 big-endian multilib usrmerge (symlink in correct place)
 DEFAULTTUNE = "aarch64_be"
 DISTRO_FEATURES += "usrmerge"
 MACHINE = "qemuarm64"
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
 require conf/multilib.conf

* x86 (real loader in correct place)
 MACHINE = "qemux86"

[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-November/276120.html

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 .../glibc/glibc-loader-symlink.bb             | 27 +++++++++++++++++++
 meta/recipes-core/glibc/glibc-package.inc     | 20 +++++---------
 2 files changed, 34 insertions(+), 13 deletions(-)
 create mode 100644 meta/recipes-core/glibc/glibc-loader-symlink.bb

Patch hide | download patch | download mbox

diff --git a/meta/recipes-core/glibc/glibc-loader-symlink.bb b/meta/recipes-core/glibc/glibc-loader-symlink.bb
new file mode 100644
index 0000000000..737d23f0d1
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc-loader-symlink.bb
@@ -0,0 +1,27 @@ 
+# On AArch64, at least glibc will RDEPEND on this recipe in order to
+# ensure that the dynamic loader is available in the ABI-mandated
+# location when that location differs from where glibc installed it.
+# This happens when multilib is enabled.
+
+SUMMARY = "AArch64 compatibility symlink when using multilib"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+INSANE_SKIP_${PN}_append_aarch64 = " libdir"
+FILES_${PN} = "${root_prefix}/lib"
+
+do_install_aarch64() {
+    if [ "${base_libdir}" != "${root_prefix}/lib" ]; then
+        # The aarch64 ABI says the dynamic linker -must- be /lib/ld-linux-aarch64[_be].so.1
+        install -d ${D}${root_prefix}/lib
+        if [ "${ARMPKGARCH}" = "aarch64" ]; then
+            ln -s ${@oe.path.relative('${root_prefix}/lib', '${base_libdir}')}/ld-linux-aarch64.so.1 \
+                  ${D}${root_prefix}/lib/ld-linux-aarch64.so.1
+        elif [ "${ARMPKGARCH}" = "aarch64_be" ]; then
+            ln -s ${@oe.path.relative('${root_prefix}/lib', '${base_libdir}')}/ld-linux-aarch64_be.so.1 \
+                  ${D}${root_prefix}/lib/ld-linux-aarch64_be.so.1
+        else
+            false
+        fi
+    fi
+}
diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc
index a98ae1a29c..9c3f5bc355 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -15,8 +15,6 @@  RPROVIDES_glibc-thread-db = "eglibc-thread-db"
 RPROVIDES_${PN}-pcprofile = "eglibc-pcprofile"
 RPROVIDES_${PN}-dbg = "eglibc-dbg"
 libc_baselibs = "${base_libdir}/libc.so.* ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* ${base_libdir}/libm-*.so ${base_libdir}/libmvec-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
-libc_baselibs_append_aarch64 = " /lib/ld-linux-aarch64*.so.1"
-INSANE_SKIP_${PN}_append_aarch64 = " libdir"
 
 FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf"
 FILES_ldd = "${bindir}/ldd"
@@ -44,6 +42,13 @@  FILES_glibc-thread-db = "${base_libdir}/libthread_db.so.* ${base_libdir}/libthre
 RPROVIDES_${PN}-dev += "libc-dev"
 RPROVIDES_${PN}-staticdev += "libc-staticdev"
 
+# For AArch64 at least, we need to ensure that the dynamic loader is
+# available by the ABI-mandated path in /lib. This will always be true
+# if ${base_libdir} is /lib (or perhaps /usr/lib when usrmerge is
+# enabled), but we need to depend on glibc-loader-symlink to provide
+# it otherwise.
+RDEPENDS_${PN}_aarch64 = "${@oe.utils.conditional('base_libdir', '${root_prefix}/lib', '', 'glibc-loader-symlink', d)}"
+
 SUMMARY_sln = "The static ln"
 DESCRIPTION_sln = "Similar to the 'ln' utility, but statically linked.  sln is useful to make symbolic links to dynamic libraries if the dynamic linking system, for some reason, is not functional."
 SUMMARY_nscd = "Name service cache daemon"
@@ -115,17 +120,6 @@  do_install_append () {
 }
 
 do_install_append_aarch64 () {
-	if [ "${base_libdir}" != "${nonarch_base_libdir}" ]; then
-		# The aarch64 ABI says the dynamic linker -must- be /lib/ld-linux-aarch64[_be].so.1
-		install -d ${D}${nonarch_base_libdir}
-		if [ -e ${D}${base_libdir}/ld-linux-aarch64.so.1 ]; then
-			ln -s ${@oe.path.relative('${nonarch_base_libdir}', '${base_libdir}')}/ld-linux-aarch64.so.1 \
-				${D}${nonarch_base_libdir}/ld-linux-aarch64.so.1
-		elif [ -e ${D}${base_libdir}/ld-linux-aarch64_be.so.1 ]; then
-			ln -s ${@oe.path.relative('${nonarch_base_libdir}', '${base_libdir}')}/ld-linux-aarch64_be.so.1 \
-				${D}${nonarch_base_libdir}/ld-linux-aarch64_be.so.1
-		fi
-	fi
 	do_install_armmultilib
 }
 

Comments

Richard Purdie Jan. 11, 2019, 4:53 p.m.
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
Mike Crowe Jan. 11, 2019, 4:59 p.m.
On Friday 11 January 2019 at 16:53:47 +0000, Richard Purdie wrote:
> 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 :(.

This is how far I got before deciding that it was too ugly. This patch
needs some cleaning up, and similar hackery to the separate-recipe patch
because the aarch64-be override doesn't work. :(

I tried to make both patches at least slightly generic in case some other
architecture needs something similar in the future. That's why the code has
moved into a plain do_install_append. This isn't required though, and
perhaps it would be clearer if the variable were actually
AARCH64_DYNAMIC_LOADER anyway.

Thanks.

Mike.