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.
