From mboxrd@z Thu Jan  1 00:00:00 1970
From: Luca Ceresoli <luca@lucaceresoli.net>
Date: Wed, 23 Apr 2014 13:06:23 +0200
Subject: [Buildroot] ld-linux.so.3 problem with external EABIhf toolchain
Message-ID: <53579EAF.3020701@lucaceresoli.net>
List-Id: <buildroot.busybox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: buildroot@busybox.net

Hi all, Thomas,

I'm in the middle of updating a project from Buildroot 2013.08 to
2013.11, but I hit a problem with the external toolchain installation.

The project uses an external ARMv7 EABIhf toolchain (no multilib)
previously built with crosstool-NG, installed on the build host.

Between 2013.08 and 2013.11 lies (*) this commit:

 >  commit 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2
 >  Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 >  Date:   Tue Oct 8 20:17:15 2013 +0200
 >
 >      toolchain-external: fix Linaro ARM toolchain support
 >
...
 >
 >  -LIB_EXTERNAL_LIBS+=ld*.so.* libc.so.* libcrypt.so.* libdl.so.* 
libgcc_s.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
 >  +LIB_EXTERNAL_LIBS+=libc.so.* libcrypt.so.* libdl.so.* libgcc_s.so.* 
libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
 >  +ifeq ($(BR2_ARM_EABIHF),y)
 >  +LIB_EXTERNAL_LIBS+=ld-linux-armhf.so.*
 >  +else
 >  +LIB_EXTERNAL_LIBS+=ld*.so.*
 >  +endif

Here when an EABIhf toolchain is used, ld-2.13.so and ld-linux.so.3 are
not installed on the target. This is for Linaro toolchains.

My toolchain is EABIhf, but ships ld-2.13.so and ld-linux.so.3.

So the commit above breaks runtime execution of nearly every executable
(including busybox init), since no ld-linux is installed on the target.

The following dirty hack solves my own use case:

  ifeq ($(BR2_ARM_EABIHF),y)
-LIB_EXTERNAL_LIBS+=ld-linux-armhf.so.*
+LIB_EXTERNAL_LIBS+=ld-linux-armhf.so.* ld*.so.*
  else
  LIB_EXTERNAL_LIBS+=ld*.so.*
  endif

I wonder which may be the best way to fix it properly without breaking
other toolchains.

Is there a specific reason for having a different dynamic loader naming
in ARM EABIhf toolchains? Or is it just that, by coincidence, all
EABIhf toolchains supported by Buildroot (=Linaro) happen to do so?

Thanks.

(*) "lies", meaning it rests there, not meaning it tells the false;
     indeed it tells the Truth (it fixes Linaro toolchains), but not all
     of the Truth (it does not tell it breaks _my_ toolchain). ;-)

-- 
Luca