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.
GCC 14 libsanitizer no longer depends on crypt.h. But let's keep this
option for reducing build time, just update the explanation.
Also remove libxcrypt from GCC depedency list.
Update to vim-9.1.0405.
Update to util-linux-2.40.1.
Update to linux-6.8.9.
Update to jinja2-3.1.4 (Python mpdule).
Update to iana-etc-20240502.
Update to gcc-14.1.0.
The effect will not change, but with symlinks ld can save some time
invoking open(), read(), etc. syscalls and parsing the linker scripts.
Note that I've also removed "libcursesw" symlink because this library
has never existed. Instead libcurses.so is created as a symlink
direct to libncursesw.so.
instead of the 8-bit ncurses.
We don't provide the 8-bit ncurses library and we are "faking" it using
ncursesw. Thus innocent package may be compiled with the 8-bit ABI
(because it does not know what we are doing and so it does not use
the "expected" preprocessor definitions to enable the wide ABI) but
linked against ncursesw, causing a potential ABI mismatch.
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...
