From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] ld-linux.so.3 problem with external EABIhf toolchain
Date: Wed, 23 Apr 2014 17:16:46 +0200 [thread overview]
Message-ID: <5357D95E.7040100@mind.be> (raw)
In-Reply-To: <CAFbHwiQFveiQfjbGDW0+78akYmid7+PpNr3sJGe68PF0-7ASXg@mail.gmail.com>
On 23/04/14 13:27, Will Newton wrote:
> On Wed, Apr 23, 2014 at 12:06 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
>> 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?
>
> Linaro toochains do this renaming of ld.so to support multilibs (in
> other words supporting both hard and soft float on the same system).
> It seems like it should be safe to install all ld*.so.* in either case
> but I am sure Thomas has thought about this a lot harder than I have!
So probably a buildroot toolchain that is used as an external toolchain
would expose the same issue...
Actually, it looks like there is no br-arm-*-gnueabihf toolchain on
http://autobuild.buildroot.net/toolchains, perhaps that should be added?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
prev parent reply other threads:[~2014-04-23 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 11:06 [Buildroot] ld-linux.so.3 problem with external EABIhf toolchain Luca Ceresoli
2014-04-23 11:27 ` Will Newton
2014-04-23 15:16 ` Arnout Vandecappelle [this message]
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=5357D95E.7040100@mind.be \
--to=arnout@mind.be \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.