[lfs-dev] Binutils >= 2.27 and seg fault when using glibc pass 1

Bruce Dubbs bruce.dubbs at gmail.com
Fri Aug 5 14:34:33 PDT 2016

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

   -- Bruce

More information about the lfs-dev mailing list