[Buildroot] Bug in RPATH fixing logic
Wolfgang Grandegger
wg at grandegger.com
Mon Nov 13 07:17:20 UTC 2017
Hello,
Am 12.11.2017 um 18:42 schrieb Yann E. MORIN:
> On 2017-11-12 18:24 +0100, Thomas Petazzoni spake thusly:
>> Hello,
>>
>> On Sun, 12 Nov 2017 18:15:12 +0100, Peter Korsgaard wrote:
>>
>>> > So this happens because the ARC binutils version is fetched from Git,
>>> > so we need to have host-flex installed, and binutils detects the flex
>>> > library and decides to use it.
>>>
>>> And there is no configure flag to disable that?
>>
>> Not that I can see.
>
> A long time ago (when I was too young to have a beard), libfl was only
> available as a static library.
>
> That library contained (and stil contains) a 'main()' symbol (is it even
> a weak one?), so it really is a weird library to begin with... I would
> not mind building that host library with --disable-shared --enable-static
> and only install the static library...
>
> That would solve this specific issue.
>
> Until we need another library...
>
>>> >> - The absolute rpath in $(HOST_DIR)/<tuple>/bin/ar is wrong in the
>>> >> first place, but I'm not sure how to fix this.
>>>
>>> > I'm wrong on this: $(HOST_DIR)/<tuple>/bin/ar RPATH is totally fine:
>>>
>>> > $ readelf -d arc-buildroot-linux-uclibc/bin/ar | grep rpath
>>> > 0x000000000000000f (RPATH) Library rpath: [/opt/br-arcle-hs38-full-2017.11-rc1/lib]
>>>
>>> > The problem is that this gets turned into $ORIGIN/../lib by patchelf.
>>>
>>> > I don't see any other solution than de-duplicating such binaries.
>>>
>>> > Do you see another option ?
>>>
>>> Not if we *need* both binaries (do we?)
>>
>> I think we do need both binaries. <tuple>-<tool> is the "publicly"
>> visible copy, while <tuple>/bin/<tool> is the one called internally by
>> gcc (for example when it calls as or ld). Yann can explain more about
>> this perhaps.
>
> I can't explain much more than you did, sorry...
>
>>> Is there a way to get binutils to use soft links instead of hard links?
>>
>> How would this solve the problem?
>
> I guess the reasoning of Peter was that maybe $ORIGIN is relative to the
> real file not the symlink.
>
> Thus by having <tuple>/bin/<tool> a symlink to ../../bin/<tuple>-<tool>
> would solve the issue.
>
> But I am not sure of it either, and the manpage for ld.so does not
> mention that. It only states:
>
> $ORIGIN (or equivalently ${ORIGIN})
> This expands to the directory containing the program or
> shared object.
>
> No mention of the behaviour when the program is being called through a
> symlink in another directory... :-/
A symlink seem to be resolved before using $ORIGIN:
$ cd <buildroot-build-dir>
$ ldd host/bin/xgettext
...
libgettextsrc-0.19.8.1.so => /work/bdo/dcu/host/bin/../lib/libgettextsrc-0.19.8.1.so (0x00007f2ae6832000)
libgettextlib-0.19.8.1.so => /work/bdo/dcu/host/bin/../lib/libgettextlib-0.19.8.1.so (0x00007f2ae652f000)
# Hard link
$ ln host/bin/xgettext xgettext
$ ./xgettext
./xgettext: error while loading shared libraries: libgettextsrc-0.19.8.1.so: cannot open shared object file: No such file or directory
# Soft link:
$ rm xgettext
$ ln -s ost/bin/xgettext xgettext
$ ./xgettext
./xgettext: Eingabedatei fehlt
But:
$ ldd xgettext
...
libgettextsrc-0.19.8.1.so => not found
libgettextlib-0.19.8.1.so => not found
This means: A symbolic link would work.
Wofgang.
More information about the buildroot
mailing list