| Message ID | 1379411093-37240-1-git-send-email-greg.beresford@zbdsolutions.com |
|---|---|
| State | Superseded |
| Headers | show |
Hi Greg, On Tue, Sep 17, 2013 at 5:44 AM, Greg Beresford <greg.beresford@zbdsolutions.com> wrote: > From: Henry Luis <henry@echelon.com> > > Arch-specific libraries, including libc.so.6, are expected to be in a > subdirectory of /lib (e.g. /lib/arm-linux-gnueabihf). This patch > changes copy_toolchain_lib_root() in helper.mk to preserve the > toolchain sysroot's lib directory structure, except for SUPPORT_LIB_DIR > which are still copied directly under DESTDIR. > > Signed-off-by: Greg Beresford <greg.beresford@zbdsolutions.com> > --- Thanks for posting the patch. I've been trying it out, but I think that I'm running into a bigger problem of how the shared library search path works now. I.e. /usr/lib is not searched by default anymore even though that's where many buildroot packages install their libraries. Here's the new search path: /lib/arm-linux-gnueabihf/ /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/ /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/ /usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/ /usr/lib/arm-linux-gnueabihf/tls/v7l/ /usr/lib/arm-linux-gnueabihf/tls/neon/vfp/ /usr/lib/arm-linux-gnueabihf/tls/neon/ /usr/lib/arm-linux-gnueabihf/tls/vfp/ /usr/lib/arm-linux-gnueabihf/tls/ /usr/lib/arm-linux-gnueabihf/v7l/neon/vfp/ /usr/lib/arm-linux-gnueabihf/v7l/neon/ /usr/lib/arm-linux-gnueabihf/v7l/vfp/ /usr/lib/arm-linux-gnueabihf/v7l/ /usr/lib/arm-linux-gnueabihf/neon/vfp/ I can think of a few hacks to get around this, but is there a right way that I should be configuring buildroot to deal with this multiarch/multilib toolchain feature? Thanks, Frank > > I couldn't initially see a particularly clear way of removing the pushd > and popd commands, but the below worked (once I figured out how escape > it properly.) > > Regards > Greg > > toolchain/helpers.mk | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk > index 0e270ee..3b4900d 100644 > --- a/toolchain/helpers.mk > +++ b/toolchain/helpers.mk > @@ -66,12 +66,17 @@ copy_toolchain_lib_root = \ > LIBDIR=`dirname $${LIBPATH}` ; \ > while test \! -z "$${LIBNAME}" ; do \ > LIBPATH=$${LIBDIR}/$${LIBNAME} ; \ > - rm -fr $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \ > - mkdir -p $(TARGET_DIR)/$${DESTDIR}; \ > + if [ "$${dir}" = "$${SUPPORT_LIB_DIR}" ]; then \ > + DDIR=$${DESTDIR} ; \ > + else \ > + DDIR=$${LIBDIR\#$${ARCH_SYSROOT_DIR}} ; \ > + fi; \ > + rm -fr $(TARGET_DIR)/$${DDIR}/$${LIBNAME}; \ > + mkdir -p $(TARGET_DIR)/$${DDIR}; \ > if test -h $${LIBPATH} ; then \ > - cp -d $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/; \ > + cp -d $${LIBPATH} $(TARGET_DIR)/$${DDIR}/; \ > elif test -f $${LIBPATH}; then \ > - $(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \ > + $(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DDIR}/$${LIBNAME}; \ > else \ > exit -1; \ > fi; \ > -- > 1.8.4 > > > > Disclaimer: This email contains proprietary information some or all of which may be legally privileged and/or is confidential. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, distribute, copy or print this email. Any views expressed in this message are those of the individual sender, except where the message states otherwise. ZBD Displays accepts no responsibility for any computer virus which might be transferred by way of this email. We may monitor all email communication through our networks. If you contact us by email, we may store your name and address to facilitate communication. ZBD Displays Ltd is registered in England and Wales, company registration number: 03929602. Registered Office: Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ, UK > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Dear Frank Hunleth, On Tue, 17 Sep 2013 13:01:14 -0400, Frank Hunleth wrote: > Thanks for posting the patch. I've been trying it out, but I think > that I'm running into a bigger problem of how the shared library > search path works now. I.e. /usr/lib is not searched by default > anymore even though that's where many buildroot packages install their > libraries. > > Here's the new search path: > > /lib/arm-linux-gnueabihf/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/ > /usr/lib/arm-linux-gnueabihf/tls/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/neon/ > /usr/lib/arm-linux-gnueabihf/tls/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/ > /usr/lib/arm-linux-gnueabihf/v7l/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/v7l/neon/ > /usr/lib/arm-linux-gnueabihf/v7l/vfp/ > /usr/lib/arm-linux-gnueabihf/v7l/ > /usr/lib/arm-linux-gnueabihf/neon/vfp/ > > I can think of a few hacks to get around this, but is there a right > way that I should be configuring buildroot to deal with this > multiarch/multilib toolchain feature? I haven't had the time yet to try the patch and experiment with this problem specifically, but I believe one of the possible solutions is to continue to install the libraries in /lib and /usr/lib, and creates /lib/arm-linux-gnueabihf/ -> /lib and /usr/lib/arm-linux-gnueabihf/ -> /usr/lib symbolic links. Thomas
Hi Frank > -----Original Message----- > From: Frank Hunleth [mailto:fhunleth@troodon-software.com] > Sent: 17 September 2013 18:01 > To: Greg Beresford > Cc: buildroot; Henry Luis > Subject: Re: [Buildroot] [PATCH v2] Add support for eglibc-2.17 multiarch > layout, from Linaro 2013.07+ > > Hi Greg, > > On Tue, Sep 17, 2013 at 5:44 AM, Greg Beresford > <greg.beresford@zbdsolutions.com> wrote: > > From: Henry Luis <henry@echelon.com> > > > > Arch-specific libraries, including libc.so.6, are expected to be in a > > subdirectory of /lib (e.g. /lib/arm-linux-gnueabihf). This patch > > changes copy_toolchain_lib_root() in helper.mk to preserve the > > toolchain sysroot's lib directory structure, except for SUPPORT_LIB_DIR > > which are still copied directly under DESTDIR. > > > > Signed-off-by: Greg Beresford <greg.beresford@zbdsolutions.com> > > --- > > Thanks for posting the patch. I've been trying it out, but I think > that I'm running into a bigger problem of how the shared library > search path works now. I.e. /usr/lib is not searched by default > anymore even though that's where many buildroot packages install their > libraries. > > Here's the new search path: > > /lib/arm-linux-gnueabihf/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/v7l/ > /usr/lib/arm-linux-gnueabihf/tls/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/neon/ > /usr/lib/arm-linux-gnueabihf/tls/vfp/ > /usr/lib/arm-linux-gnueabihf/tls/ > /usr/lib/arm-linux-gnueabihf/v7l/neon/vfp/ > /usr/lib/arm-linux-gnueabihf/v7l/neon/ > /usr/lib/arm-linux-gnueabihf/v7l/vfp/ > /usr/lib/arm-linux-gnueabihf/v7l/ > /usr/lib/arm-linux-gnueabihf/neon/vfp/ > > I can think of a few hacks to get around this, but is there a right > way that I should be configuring buildroot to deal with this > multiarch/multilib toolchain feature? > I've investigated a little more and found that the only reason my setup works is because one of my packages is running ldconfig in my target directory, so the dynamic linker is finding my libraries correctly because they're all listed in /etc/ld.so.cache. If we're not going to make use of the multi-abi feature of the recent linaro toolchains we should probably have a symlink-based solution as Thomas has suggested. Regards Greg Disclaimer: This email contains proprietary information some or all of which may be legally privileged and/or is confidential. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, distribute, copy or print this email. Any views expressed in this message are those of the individual sender, except where the message states otherwise. ZBD Displays accepts no responsibility for any computer virus which might be transferred by way of this email. We may monitor all email communication through our networks. If you contact us by email, we may store your name and address to facilitate communication. ZBD Displays Ltd is registered in England and Wales, company registration number: 03929602. Registered Office: Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ, UK
Hi Greg and Thomas, On Wed, Sep 18, 2013 at 5:32 AM, Greg Beresford <greg.beresford@zbdsolutions.com> wrote: > Hi Frank > >> -----Original Message----- >> From: Frank Hunleth [mailto:fhunleth@troodon-software.com] >> Sent: 17 September 2013 18:01 >> To: Greg Beresford >> Cc: buildroot; Henry Luis >> Subject: Re: [Buildroot] [PATCH v2] Add support for eglibc-2.17 multiarch >> layout, from Linaro 2013.07+ >> >> Hi Greg, >> >> On Tue, Sep 17, 2013 at 5:44 AM, Greg Beresford >> <greg.beresford@zbdsolutions.com> wrote: >> > From: Henry Luis <henry@echelon.com> >> > >> > Arch-specific libraries, including libc.so.6, are expected to be in a >> > subdirectory of /lib (e.g. /lib/arm-linux-gnueabihf). This patch >> > changes copy_toolchain_lib_root() in helper.mk to preserve the >> > toolchain sysroot's lib directory structure, except for SUPPORT_LIB_DIR >> > which are still copied directly under DESTDIR. >> > >> > Signed-off-by: Greg Beresford <greg.beresford@zbdsolutions.com> >> > --- >> >> Thanks for posting the patch. I've been trying it out, but I think >> that I'm running into a bigger problem of how the shared library >> search path works now. I.e. /usr/lib is not searched by default >> anymore even though that's where many buildroot packages install their >> libraries. >> >> Here's the new search path: >> >> /lib/arm-linux-gnueabihf/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/ >> /usr/lib/arm-linux-gnueabihf/tls/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/neon/ >> /usr/lib/arm-linux-gnueabihf/tls/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/ >> /usr/lib/arm-linux-gnueabihf/v7l/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/v7l/neon/ >> /usr/lib/arm-linux-gnueabihf/v7l/vfp/ >> /usr/lib/arm-linux-gnueabihf/v7l/ >> /usr/lib/arm-linux-gnueabihf/neon/vfp/ >> >> I can think of a few hacks to get around this, but is there a right >> way that I should be configuring buildroot to deal with this >> multiarch/multilib toolchain feature? >> > > I've investigated a little more and found that the only reason my setup works is because one of my packages is running ldconfig in my target directory, so the dynamic linker is finding my libraries correctly because they're all listed in /etc/ld.so.cache. > > If we're not going to make use of the multi-abi feature of the recent linaro toolchains we should probably have a symlink-based solution as Thomas has suggested. > I agree. Symlinks sound good to me. Frank > Regards > Greg > > > Disclaimer: This email contains proprietary information some or all of which may be legally privileged and/or is confidential. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, distribute, copy or print this email. Any views expressed in this message are those of the individual sender, except where the message states otherwise. ZBD Displays accepts no responsibility for any computer virus which might be transferred by way of this email. We may monitor all email communication through our networks. If you contact us by email, we may store your name and address to facilitate communication. ZBD Displays Ltd is registered in England and Wales, company registration number: 03929602. Registered Office: Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ, UK > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________
Hi Thomas, On Tue, Sep 17, 2013 at 2:50 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Frank Hunleth, > > On Tue, 17 Sep 2013 13:01:14 -0400, Frank Hunleth wrote: > >> Thanks for posting the patch. I've been trying it out, but I think >> that I'm running into a bigger problem of how the shared library >> search path works now. I.e. /usr/lib is not searched by default >> anymore even though that's where many buildroot packages install their >> libraries. >> >> Here's the new search path: >> >> /lib/arm-linux-gnueabihf/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/neon/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/v7l/ >> /usr/lib/arm-linux-gnueabihf/tls/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/neon/ >> /usr/lib/arm-linux-gnueabihf/tls/vfp/ >> /usr/lib/arm-linux-gnueabihf/tls/ >> /usr/lib/arm-linux-gnueabihf/v7l/neon/vfp/ >> /usr/lib/arm-linux-gnueabihf/v7l/neon/ >> /usr/lib/arm-linux-gnueabihf/v7l/vfp/ >> /usr/lib/arm-linux-gnueabihf/v7l/ >> /usr/lib/arm-linux-gnueabihf/neon/vfp/ >> >> I can think of a few hacks to get around this, but is there a right >> way that I should be configuring buildroot to deal with this >> multiarch/multilib toolchain feature? > > I haven't had the time yet to try the patch and experiment with this > problem specifically, but I believe one of the possible solutions is to > continue to install the libraries in /lib and /usr/lib, and > creates /lib/arm-linux-gnueabihf/ -> /lib > and /usr/lib/arm-linux-gnueabihf/ -> /usr/lib symbolic links. I'm not sure if you had a chance to revisit this, but I wanted to report that using symlinks works. Here's what I've temporarily added to my rootfs post build script: if [ -d $TARGETDIR/lib/arm-linux-gnueabihf -a ! -h $TARGETDIR/lib/arm-linux-gnueabihf ]; then mv $TARGETDIR/lib/arm-linux-gnueabihf/* $TARGETDIR/lib rm -fr $TARGETDIR/lib/arm-linux-gnueabihf rm -fr $TARGETDIR/lib/arm-linux-gnueabi ln -fs . $TARGETDIR/lib/arm-linux-gnueabihf ln -fs . $TARGETDIR/usr/lib/arm-linux-gnueabihf fi I'm not sure how best to integrate this with buildroot, but I've haven't had much time to work on it. I'm hoping that this may be helpful to someone fixing armhf builds when using the external toolchain option. Frank > > Thomas > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk index 0e270ee..3b4900d 100644 --- a/toolchain/helpers.mk +++ b/toolchain/helpers.mk @@ -66,12 +66,17 @@ copy_toolchain_lib_root = \ LIBDIR=`dirname $${LIBPATH}` ; \ while test \! -z "$${LIBNAME}" ; do \ LIBPATH=$${LIBDIR}/$${LIBNAME} ; \ - rm -fr $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \ - mkdir -p $(TARGET_DIR)/$${DESTDIR}; \ + if [ "$${dir}" = "$${SUPPORT_LIB_DIR}" ]; then \ + DDIR=$${DESTDIR} ; \ + else \ + DDIR=$${LIBDIR\#$${ARCH_SYSROOT_DIR}} ; \ + fi; \ + rm -fr $(TARGET_DIR)/$${DDIR}/$${LIBNAME}; \ + mkdir -p $(TARGET_DIR)/$${DDIR}; \ if test -h $${LIBPATH} ; then \ - cp -d $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/; \ + cp -d $${LIBPATH} $(TARGET_DIR)/$${DDIR}/; \ elif test -f $${LIBPATH}; then \ - $(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \ + $(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DDIR}/$${LIBNAME}; \ else \ exit -1; \ fi; \