Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] ld-linux.so.3 problem with external EABIhf toolchain
Date: Wed, 23 Apr 2014 13:06:23 +0200	[thread overview]
Message-ID: <53579EAF.3020701@lucaceresoli.net> (raw)

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

             reply	other threads:[~2014-04-23 11:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 11:06 Luca Ceresoli [this message]
2014-04-23 11:27 ` [Buildroot] ld-linux.so.3 problem with external EABIhf toolchain Will Newton
2014-04-23 15:16   ` Arnout Vandecappelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53579EAF.3020701@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox