Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Thursday 21 February 2019 at 13:01:27 +, Richard Purdie wrote: > On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote: > > On Wednesday 23 January 2019 at 16:27:59 +, 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. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote: > On Wednesday 23 January 2019 at 16:27:59 +, 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Wednesday 23 January 2019 at 16:27:59 +, Mike Crowe wrote:
> On Friday 11 January 2019 at 16:59:44 +, Mike Crowe wrote:
> > On Friday 11 January 2019 at 16:53:47 +, Richard Purdie wrote:
> > > On Fri, 2019-01-11 at 16:49 +, 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.
> > +
> > +
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Friday 11 January 2019 at 16:59:44 +, Mike Crowe wrote:
> On Friday 11 January 2019 at 16:53:47 +, Richard Purdie wrote:
> > On Fri, 2019-01-11 at 16:49 +, 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',
>
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Friday 11 January 2019 at 16:53:47 +, Richard Purdie wrote:
> On Fri, 2019-01-11 at 16:49 +, 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
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Fri, 2019-01-11 at 16:49 +, 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
[OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
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
---
.../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
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 00..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
