Romain Geissler wrote:
Hi,
Some users have reported issues when upgrading to binutils 2.27 and
following the current LFS guidelines. Here is how to fix it (sorry for
not replying to the original message, but I don't have any subscription to
the LFS mailing list, and don't know how to retrieve an old mail).
First, if you investigate a bit the issue, you will notice that the
resulting glibc from pass 1 is completely unusable, the dynamic loader
will always seg fault when trying to call the global constructors of
libc.so (in this call_init from ld-init.c in the glibc, see [1]).
If you git bisect a bit the binutils, you eventually find out that the
commit that generates these issues is [2] which changes the default
configuration from --disable-initfini-array to --enable-initfini-array. I
don't know much about this, just that it slightly changes the way the
binutils and gcc generates the global constructors/destructors method,
from .ctors/.dtors sections to .init_array/.fini_array. If you read the
different reason for this, this is apparently the "new" way of doing
things, which was supported in the full GNU toolchain for more than 10
years, but until now was not enabled by default. Using
--disable-initfini-array when configuring the binutils would be a possible
workaround, but that would mean you ignore a "new" feature the binutils
developers are trying to promote, so not really a good idea on the long
run.
On the other side, the LFS guidelines stricly force you to configure glibc
pass 1 with the argument libc_cv_ctors_header=yes. If you dig more in the
configure script, you can actually notice that this is directly linked to
the fact that we use either the "old" or "new" constructor/destructor
format. I don't know why LFS initially adviced it's users to use
libc_cv_ctors_header=yes, but now with the change in binutils 2.27 this
creates a wrong configuration. The glibc is built to work with binutils
that generated the "old" way, but actually the binutils are using the
"new" way, resulting in memory corruptions around the __CTOR_LIST__ and
__DTOR_LIST__ symbols in the glibc that aren't meant to exists when using
.init_array sections.
So in the end, to fix any issue when using binutils >= 2.27, you should
remove the flag libc_cv_ctors_header=yes when building glibc pass 1. I
have boostrapped a complete GNU toolchain following the LFS guidelines and
this tiny change on x86_64, run the tests of the final system gcc, glibc
and binutils, and all went well (I don't run the test suites on the
temporary system though).
Hope that helps.
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-init.c;h=818c3aa37cd052e6edbf5f55524647b45b5bfe87;hb=ab30899d880f9741a409cbc0d7a28399bdac21bf#l72
[2] https://sourceware.org/ml/binutils-cvs/2015-12/msg00016.html
Yes, it helps a lot. I'll give that a try next. Right now I am running a
test with some changes for gcc to be compatible with glibc-2.24.
Those changes seem to make a test in findutils hang so the latest changes
in both glibc and binutils are causing changes for LFS.
Thank you.
BTW, all the messages for the -dev mailing list are at
http://lists.linuxfromscratch.org/pipermail/lfs-dev/
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
