Pass 2 libstdc++ still links to libgcc.a even with LDFLAGS_FOR_TARGET=,
despite this libgcc.a is from pass 2 instead of pass 1.
The difference between pass 2 libgcc and pass 1 libgcc is Glibc wasn't
installed when the pass 1 libgcc was built. This difference causes both
consequences (1) pass 1 libgcc lacks shared library and (2) pass 1
libgcc cannot support C++ EH, but it's not (1) causing (2).
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.
I've proposed a backport of the change to GCC 13.3 but no response yet.
But even if the proposal is rejected I'd still have no choice but
backporting downstream. So just do it.
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...
- Update to systemd-253
- Update to bc-6.3.1
- Update to linux-6.2.2
- Update to procps-ng-4.0.3
- Update to iproute2-6.2.0
- Update to meson-1.0.1
- Update to make-4.4.1
- Update to elfutils-0.189
We need to enable decimal float here or MPFR will be built w/o decimal
float support. Then 2 of 183 tests will be skipped, and this will also
cause an ICA issue.
Q: Why we need decimal float in pass 1?
A: We need pass-1 GCC with decimal float support to build decimal float
routines in pass-2 libgcc.
Fix make-4.4 bug.
Update to wheel-0.38.4 (Python Module).
Update to texinfo-7.0.
Update to sysvinit-3.05.
Update to shadow-4.13.
Update to sed-4.9.
Update to meson-0.64.0.
Update to linux-6.0.7.
Update to elfutils-0.188.
Update to bc-6.1.1.
