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.
Committing only the commands for now, so that others can test the
build. TODO:
- add command explanations
- add changelog
- comment on failing tests in binutils and gcc
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.
Presently we let the build system generate static C++ bindings, and
then we remove them. Note that we could also prevent generating
any C++ binding, since nothing in LFS/BLFS use them, but it seems to
me that generating the shared ones is closer to what is done for
other packages.
