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.
It works out of box with glibc-2.35. I think this issue is already
fixed at glibc side, by the commit:
commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82
Author: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue Sep 21 07:47:45 2021 -0700
regex: copy back from Gnulib
Copy regex-related files back from Gnulib, to fix a problem with
static checking of regex calls noted by Martin Sebor. This merges the
following changes:
* New macro __attribute_nonnull__ in misc/sys/cdefs.h, for use later
when copying other files back from Gnulib.
... ... (unrelated things trimmed)
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.
The c_rehash script, shipped by OpenSSL versions in current LFS trunk
and all previous LFS releases, is vulnerable to CVE-2022-2068. It's
fixed in 3.0.4, but OpenSSL 3.0.4 is completely broken on CPU models with
AVX-512 extension [1]. So we'd like to defer OpenSSL update and wait for
upstream consensus about "would 3.0.5 be released in urgency".
But, the upstream has announced that use of c_rehash is obsolete now [2].
So we can tell people not to use it.
[1]: https://github.com/openssl/openssl/issues/18625
[2]: https://www.openssl.org/news/secadv/20220621.txt
