[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.
Mike Crowe Jan. 23, 2019, 4:27 p.m.
On Friday 11 January 2019 at 16:59:44 +0000, Mike Crowe wrote:
> 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.
> 
> diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc
> index a98ae1a29c..0181aa7b32 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -15,7 +15,13 @@ 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"
> +ARCH_DYNAMIC_LOADER = ""
> +# The aarch64 ABI says the dynamic linker -must- be
> +# /lib/ld-linux-aarch64[_be].so.1. With usrmerge, that may mean that
> +# we need to install it in /usr/lib.
> +ARCH_DYNAMIC_LOADER_aarch64 = "ld-linux-aarch64.so.1"
> +ARCH_DYNAMIC_LOADER_aarch64_be = "ld-linux-aarch64_be.so.1"
> +libc_baselibs_append = " ${@oe.utils.conditional('ARCH_DYNAMIC_LOADER', '', '', '${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}', d)}"
>  INSANE_SKIP_${PN}_append_aarch64 = " libdir"
> 
>  FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf"
> @@ -112,20 +118,20 @@ do_install_append () {
>  		echo "d root root 0755 /var/run/nscd none" \
>  			> ${D}${sysconfdir}/default/volatiles/98_nscd
>  	fi
> +
> +	# The dynamic loader will have been installed into
> +	# ${base_libdir}. However, if that isn't going to end up being
> +	# available in the ABI-mandated location, then a symlink must
> +        # be created.
> +
> +	if [ -n "${ARCH_DYNAMIC_LOADER}" -a ! -e "${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
> +		install -d ${D}${root_prefix}/lib
> +		ln -s ${@oe.path.relative('${root_prefix}/lib', '${base_libdir}')}/${ARCH_DYNAMIC_LOADER} \
> +				${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}
> +	fi
>  }
> 
>  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
>  }
> 
> @@ -207,7 +213,7 @@ do_poststash_install_cleanup () {
>  	rm -rf ${D}/${localedir}
>  	rm -rf ${D}${datadir}/locale
>  	if [ "${libdir}" != "${exec_prefix}/lib" ]; then
> -		if [ -d ${D}${exec_prefix}/lib ]; then
> +		if [ -d ${D}${exec_prefix}/lib -a ! -e "${D}${exec_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
>  			# error out if directory isn't empty
>  			# this dir should only contain locale dir
>  			# which has been deleted in the previous step

Hi Richard (and anyone else),

Does the lack of response mean that both approaches are horrendous? If so,
do you have any better ideas?

Thanks.

Mike.
Mike Crowe Feb. 20, 2019, 4:47 p.m.
On Wednesday 23 January 2019 at 16:27:59 +0000, Mike Crowe wrote:
> On Friday 11 January 2019 at 16:59:44 +0000, Mike Crowe wrote:
> > 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.
> > 
> > diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc
> > index a98ae1a29c..0181aa7b32 100644
> > --- a/meta/recipes-core/glibc/glibc-package.inc
> > +++ b/meta/recipes-core/glibc/glibc-package.inc
> > @@ -15,7 +15,13 @@ 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"
> > +ARCH_DYNAMIC_LOADER = ""
> > +# The aarch64 ABI says the dynamic linker -must- be
> > +# /lib/ld-linux-aarch64[_be].so.1. With usrmerge, that may mean that
> > +# we need to install it in /usr/lib.
> > +ARCH_DYNAMIC_LOADER_aarch64 = "ld-linux-aarch64.so.1"
> > +ARCH_DYNAMIC_LOADER_aarch64_be = "ld-linux-aarch64_be.so.1"
> > +libc_baselibs_append = " ${@oe.utils.conditional('ARCH_DYNAMIC_LOADER', '', '', '${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}', d)}"
> >  INSANE_SKIP_${PN}_append_aarch64 = " libdir"
> > 
> >  FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf"
> > @@ -112,20 +118,20 @@ do_install_append () {
> >  		echo "d root root 0755 /var/run/nscd none" \
> >  			> ${D}${sysconfdir}/default/volatiles/98_nscd
> >  	fi
> > +
> > +	# The dynamic loader will have been installed into
> > +	# ${base_libdir}. However, if that isn't going to end up being
> > +	# available in the ABI-mandated location, then a symlink must
> > +        # be created.
> > +
> > +	if [ -n "${ARCH_DYNAMIC_LOADER}" -a ! -e "${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
> > +		install -d ${D}${root_prefix}/lib
> > +		ln -s ${@oe.path.relative('${root_prefix}/lib', '${base_libdir}')}/${ARCH_DYNAMIC_LOADER} \
> > +				${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}
> > +	fi
> >  }
> > 
> >  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
> >  }
> > 
> > @@ -207,7 +213,7 @@ do_poststash_install_cleanup () {
> >  	rm -rf ${D}/${localedir}
> >  	rm -rf ${D}${datadir}/locale
> >  	if [ "${libdir}" != "${exec_prefix}/lib" ]; then
> > -		if [ -d ${D}${exec_prefix}/lib ]; then
> > +		if [ -d ${D}${exec_prefix}/lib -a ! -e "${D}${exec_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
> >  			# error out if directory isn't empty
> >  			# this dir should only contain locale dir
> >  			# which has been deleted in the previous step
> 
> Does the lack of response mean that both approaches are horrendous? If so,
> do you have any better ideas?

There doesn't seem to be much interest in this one.

The only other idea I've had is to create the symlink at rootfs-creation
time. However, that seems to be detaching it too much from glibc, which
would cause confusion.

I can apply one of my fixes locally (we currently have some far uglier
hacks than these that I'd like to remove), but I'd really rather not have
to diverge from upstream this much.

Thanks.

Mike.
Richard Purdie Feb. 21, 2019, 1:01 p.m.
On Wed, 2019-02-20 at 16:47 +0000, Mike Crowe wrote:
> On Wednesday 23 January 2019 at 16:27:59 +0000, Mike Crowe wrote:
> > 
> > Does the lack of response mean that both approaches are horrendous?
> > If so, do you have any better ideas?
> 
> There doesn't seem to be much interest in this one.
> 
> The only other idea I've had is to create the symlink at rootfs-creation
> time. However, that seems to be detaching it too much from glibc, which
> would cause confusion.
> 
> I can apply one of my fixes locally (we currently have some far uglier
> hacks than these that I'd like to remove), but I'd really rather not have
> to diverge from upstream this much.

Sorry for the lack of feedback.

I'm fairly strongly against a separate aarch64 only recipe for this.
Realistically we therefore have to fix this in the existing
class/code/recipe.

The changes you sent previously didn't look that horrific, did you find
a working version of that?

I'm wondering if we can come up with something which works and
hopefully we can spot some way to then clean it up to be a bit nicer...

The delay was that I was going to try and come up with something but
that hasn't happened yet. If you have a horrific non-separate recipe
version that is complete, we can see if we can do anything to improve
it.

Cheers,

Richard
Mike Crowe Feb. 21, 2019, 1:25 p.m.
On Thursday 21 February 2019 at 13:01:27 +0000, Richard Purdie wrote:
> On Wed, 2019-02-20 at 16:47 +0000, Mike Crowe wrote:
> > On Wednesday 23 January 2019 at 16:27:59 +0000, Mike Crowe wrote:
> > > 
> > > Does the lack of response mean that both approaches are horrendous?
> > > If so, do you have any better ideas?
> > 
> > There doesn't seem to be much interest in this one.
> > 
> > The only other idea I've had is to create the symlink at rootfs-creation
> > time. However, that seems to be detaching it too much from glibc, which
> > would cause confusion.
> > 
> > I can apply one of my fixes locally (we currently have some far uglier
> > hacks than these that I'd like to remove), but I'd really rather not have
> > to diverge from upstream this much.
> 
> Sorry for the lack of feedback.
> 
> I'm fairly strongly against a separate aarch64 only recipe for this.
> Realistically we therefore have to fix this in the existing
> class/code/recipe.
> 
> The changes you sent previously didn't look that horrific, did you find
> a working version of that?
> 
> I'm wondering if we can come up with something which works and
> hopefully we can spot some way to then clean it up to be a bit nicer...
> 
> The delay was that I was going to try and come up with something but
> that hasn't happened yet. If you have a horrific non-separate recipe
> version that is complete, we can see if we can do anything to improve
> it.

I had suspected that was the reason for the delay.

I shall knock my modifications to glibc-package.inc into shape and send a
tested patch. I've already improved it a little compared to the version I
sent previously.

Thanks for the response.

Mike.