This option makes ld use DT_RUNPATH instead of DT_RPATH. DT_RPATH is
generally considered bad because it takes precedence over
LD_LIBRARY_PATH. For example, eog is linked with -rpath /usr/lib/eog,
and with DT_RPATH if an old eog is already installed we are basically
impossible to debug a new eog build w/o overwriting the system
installation first or explicitly using "ld.so --inhibit-rpath" to
invoke it.
This "new" actually means "new in 2000," it's 24 years ago and all other
distros has enabled it. Thus I guess some unexplainable "test suite
uses installed library instead of the just built one" issues in BLFS are
actually caused by this difference: the package author just assumes
everyone is using DT_RUNPATH thus they just set LD_LIBRARY_PATH and
consider it enough to test with the just built libraries, but DT_RPATH
breaks this expectation.
Let's eliminate the difference as it seems not doing anything good and
doing so just takes one switch.
Well, I was blaming libtool too much. If the entire Binutils tree uses
libtool this won't happen. The problem is Binutils building system is
using libtool-style idiom on non-libtool components.
And this issue is not related to cross compiling, at all. A native
build can exploit the issue as well (see the updated comment).
Maybe I'll submit a patch to GCC (yes, not a typo, GCC is the upstream
of Binutils building system) to fix the issue when I have the mood...
They are really harmful. In Binutils pass 2, libstdc++.la caused the
building system to use host /usr/lib/libstdc++.so for gprofng. We now
has disabled gprofng for pass 2, but the similar issue also exists in
GCC pass 2. In a normal LFS build, the building system silently uses
/usr/lib/libstdc++.so (I guess it does not blow up simply because some
blind luck); in a real cross build (x86 -> ARM for example) the build
will fail.
Remove the .la files to fix this issue. Instead of only modifying
clfs-ng, it makes more sense to apply the change for trunk: though
the build does not fail, using host library is still a contamination.
A very old libtool copy (2009-11-29) is shipped in binutils tarball. It
does not support sysroot, so the cross-built binutils binaries may link
to libraries from the host distro, if certain libraries are available.
The ideal solution should be updating libtool, as libtool-2.4.6 (in LFS)
has sysroot support. However, updating libtool for binutils is not
trivial: it would require to rerun autoconf and binutils building system
sticks to autoconf-2.69. Another issue is the sysroot support for
libtool has introduced a configure option "--with-sysroot", which
conflicts with an already existing option with the same name in
GCC and binutils building system (we are using the GCC/binutils version
of --with-sysroot in chapter 5).
GCC building system has --with-build-sysroot (we are using this for GCC
pass 2) for this issue. Binutils copied GCC building system, but it
does not respect --with-build-sysroot.
So for now we just edit libtool code to prevent "-L/usr/lib" in
$LFS_TGT_gcc command line. It should fix the issue about host libiberty
(reported in #lfs-support) as well, but it still need to be confirmed by
someone having such a host.
Tested with a jhalfs run on LFS.
