[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnulib use of -Wl,-rpath
From: |
Bruno Haible |
Subject: |
Re: Gnulib use of -Wl,-rpath |
Date: |
Tue, 14 May 2019 11:22:36 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; ) |
Hi,
Jeffrey Walton wrote:
> Second, here is a failed Gnulib runner. IDN's runner 3 does this:
>
> libtool: link: gcc -g2 -O2 -fsanitize=address -fno-omit-frame-pointer
> -march=native -fPIC -pthread -fsanitize=address -Wl,-R
> -Wl,/var/sanitize/lib64 -Wl,--enable-new-dtags -o tst_tld tst_tld.o
> -Wl,--no-as-needed -L/var/sanitize/lib64 libutils.a
> ../lib/.libs/libidn.so ../gl/.libs/libgnu.a -ldl -lpthread -pthread
> -Wl,-rpath -Wl,/home/build/libidn-1.35/lib/.libs -Wl,-rpath
> -Wl,/var/sanitize/lib64
> gmake[2]: Leaving directory '/home/build/libidn-1.35/tests'
> gmake check-TESTS
> gmake[2]: Entering directory '/home/build/libidn-1.35/tests'
> gmake[3]: Entering directory '/home/build/libidn-1.35/tests'
> FAIL: tst_stringprep
> FAIL: tst_punycode
> ...
In these cases, the following tools are useful (on ELF systems):
- ldd BINARY
which tells you how the runtime linker resolves the shared libraries
in the current situation,
- objdump -p BINARY | grep '\(NEEDED\|RPATH\|RUNPATH\)'
which tells you what information is encoded in the binary for the
runtime linker,
- readelf -d BINARY | grep '\(NEEDED\|RPATH\|RUNPATH\)'
likewise.
> As I understand things an RPATH cannoth be overridden by
> LD_LIBRARY_PATH, while a RUNPATH can be overridden by a
> LD_LIBRARY_PATH.
At least that's what [1] says. See also [2].
> In the failed run, notice two things.
>
> (1) my LDFLAGS (Wl,-R -Wl,/var/sanitize/lib64 -Wl,--enable-new-dtags)
> got overridden by Gnulib's LDFLAGS (-Wl,-rpath
> -Wl,/var/sanitize/lib64).
They get combined, not overridden. Multiple -R or -rpath options are
cumulative.
Did you also try -Wl,--disable-new-dtags instead of -Wl,--enable-new-dtags?
What is the outcome? Do the tests pass or fail?
> (2) Gnulib's path does not include /home/build/libidn-1.35/gl/.libs,
> which is where Gnulib is located
Yes, the LD_LIBRARY_PATH gets set in wrapper scripts that libtool
installs in the build tree, outside the .lib directories.
> My question are,
>
> (1) why id Gnulib using a rpath instead of a runpath?
The question (raised by [2]) is more: Why are some distros using a runpath
instead of an rpath, breaking 20 years of existing practice (see [3][5]
and [4])?
> (2) why is Gnulib omitting <locations>/gl/.libs frm the runpath?
Answered above.
> (3) why are runpaths being set for a static archive?
This option has no effect on static archives, I guess. Please verify this
using 'objdump' (see above).
Bruno
[1] https://news.ycombinator.com/item?id=14222349
[2]
https://stackoverflow.com/questions/52018092/how-to-set-rpath-and-runpath-with-gcc-ld
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847298
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
[5] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638