binutils > 2.21.51.0.2 fails to build glibc

[Octoploid]

Any binutils version > 2.21.51.0.2 fails to build glibc (2.12.2) on
Linux x86_64:

...
make[2]: ***
[/var/tmp/portage/sys-libs/glibc-2.12.2/work/build-amd64-x86_64-pc-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp]
Error 139
make[2]: *** Waiting for unfinished jobs....
make[2]: ***
...

I've opened a glibc bug report here:
http://sourceware.org/bugzilla/show_bug.cgi?id=12379

[Alan Modra]

Post by Octoploid
Any binutils version > 2.21.51.0.2 fails to build glibc (2.12.2) on

I just ran into this myself on x86. I think glibc probably fails to
build on any architecture. The patch that introduced the problem is
http://sourceware.org/ml/binutils/2010-12/msg00466.html

HJ, please look at fixing this. A new binutils ought to be able to
build the most recently released glibc. Actually, I guess this is not
just glibc that is broken but any binary using .ctors/.dtors that
happens to use non-standard startup file names.

A good fix might be to add EXCLUDE_INIT_SENTINEL, so that

.init_array :
{
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array))
KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
}

becomes

.init_array :
{
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array))
KEEP (*(EXCLUDE_INIT_SENTINEL(.ctors)))
}

with EXCLUDE_INIT_SENTINEL looking at .ctors section contents and
not match any section containing a single 0 or -1.

A quick and dirty workaroundk for glibc would be to add *soinit.os and
*sofini.os to the list in EXCLUDE_FILE.

[H.J. Lu]

Post by Octoploid
Any binutils version > 2.21.51.0.2 fails to build glibc (2.12.2) on

I just ran into this myself on x86.  I think glibc probably fails to
build on any architecture.  The patch that introduced the problem is
http://sourceware.org/ml/binutils/2010-12/msg00466.html
HJ, please look at fixing this.  A new binutils ought to be able to
build the most recently released glibc.  Actually, I guess this is not
just glibc that is broken but any binary using .ctors/.dtors that
happens to use non-standard startup file names.

Glibc has been fixed:

http://sourceware.org/git/?p=glibc.git;a=commit;h=4a531bb0b3b582cb693de9f76d2d97d970f9a5d5

A good fix might be to add EXCLUDE_INIT_SENTINEL, so that
 {
   KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
   KEEP (*(.init_array))
   KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
 }
becomes
 {
   KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
   KEEP (*(.init_array))
   KEEP (*(EXCLUDE_INIT_SENTINEL(.ctors)))
 }
with EXCLUDE_INIT_SENTINEL looking at .ctors section contents and
not match any section containing a single 0 or -1.

It is too fragile. I want to avoid it if possible.

[Alan Modra]

Post by H.J. Lu

Post by Octoploid
Any binutils version > 2.21.51.0.2 fails to build glibc (2.12.2) on

I just ran into this myself on x86.  I think glibc probably fails to
build on any architecture.  The patch that introduced the problem is
http://sourceware.org/ml/binutils/2010-12/msg00466.html
HJ, please look at fixing this.  A new binutils ought to be able to
build the most recently released glibc.  Actually, I guess this is not
just glibc that is broken but any binary using .ctors/.dtors that
happens to use non-standard startup file names.

http://sourceware.org/git/?p=glibc.git;a=commit;h=4a531bb0b3b582cb693de9f76d2d97d970f9a5d5

You didn't read what I said.

Post by H.J. Lu

A good fix might be to add EXCLUDE_INIT_SENTINEL, so that

It is too fragile. I want to avoid it if possible.

Do you think it is OK for a new GNU ld to without warning build older
versions of glibc that segfault at runtime?

Do you intend to fix this problem, or do you think it would be better
to revert the .ctor in .init_array support?

[H.J. Lu]

Post by Alan Modra

Post by H.J. Lu

Post by Octoploid
Any binutils version > 2.21.51.0.2 fails to build glibc (2.12.2) on

I just ran into this myself on x86.  I think glibc probably fails to
build on any architecture.  The patch that introduced the problem is
http://sourceware.org/ml/binutils/2010-12/msg00466.html
HJ, please look at fixing this.  A new binutils ought to be able to
build the most recently released glibc.  Actually, I guess this is not
just glibc that is broken but any binary using .ctors/.dtors that
happens to use non-standard startup file names.

http://sourceware.org/git/?p=glibc.git;a=commit;h=4a531bb0b3b582cb693de9f76d2d97d970f9a5d5

You didn't read what I said.

Post by H.J. Lu

A good fix might be to add EXCLUDE_INIT_SENTINEL, so that

It is too fragile. I want to avoid it if possible.

Do you think it is OK for a new GNU ld to without warning build older
versions of glibc that segfault at runtime?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Not exactly, it segfault at build-time. If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

One problem is your suggestion is for .o files with RELA relocations
checking the content of .ctor section may not be enough.

Post by Alan Modra
Do you intend to fix this problem, or do you think it would be better

I fixed the problem in glibc. .ctor isn't standard. All ELF C run-time
libraries should switch to .init_array anyway.

Post by Alan Modra
to revert the .ctor in .init_array support?

I don't think it should be reverted since that was added to provide
maximum binary compatibility when gcc is switched to .init_array.
Between the choice of unpatched glibc segfault at build-time and
stuck to .ctor forever, I choose latter.

[Ian Lance Taylor]

Post by H.J. Lu
Not exactly, it segfault at build-time. If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

That doesn't really sound OK to me....

Ian

[H.J. Lu]

Post by Ian Lance Taylor

Not exactly, it segfault at build-time.  If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

That doesn't really sound OK to me....

Glibc developers seem to have no problems.

One extra bonus is slightly smaller/faster glibc.

[Ian Lance Taylor]

Post by H.J. Lu

Post by Ian Lance Taylor

Not exactly, it segfault at build-time.  If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

That doesn't really sound OK to me....

Glibc developers seem to have no problems.

Well, no, of course they wouldn't. The issue here is not glibc
developers. It's other people who have to build glibc.

It's quite likely that I misunderstand. It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of
glibc. The linker isn't like the compiler, where we tighten
restrictions on the input language. The linker should accept old object
files. And of course it should never segfault. But if I misunderstand,
then I apologize for raising the issue.

Ian

[Alan Modra]

Post by Ian Lance Taylor
that it's OK for GNU ld to segfault when building an older version of
glibc.

It's not the linker that segfaults. ld.so does when running the newly
built libc.so .init_array entries.

HJ, another idea on fixing this: Adjust DT_{INIT,FINI}_ARRAY and
DT_{INIT,FINI}_ARRAYSZ in bfd_elf_final_link if the bogus sentinels
are detected.

[H.J. Lu]

Post by Ian Lance Taylor
that it's OK for GNU ld to segfault when building an older version of
glibc.

It's not the linker that segfaults.  ld.so does when running the newly
built libc.so .init_array entries.
HJ, another idea on fixing this:  Adjust DT_{INIT,FINI}_ARRAY and
DT_{INIT,FINI}_ARRAYSZ in bfd_elf_final_link if the bogus sentinels
are detected.

I thought about it. The bogus sentinels can be in the middle of
.init_array/.fini_array when you have priorities in .init_array/.fini_array

BTW, I understood the pain. I had to patch another C library
which has non-standard crt files. But I did get a slightly better
libc.so.

[H.J. Lu]

Post by H.J. Lu

Post by Ian Lance Taylor

Not exactly, it segfault at build-time.  If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

That doesn't really sound OK to me....

Glibc developers seem to have no problems.

Well, no, of course they wouldn't.  The issue here is not glibc
developers.  It's other people who have to build glibc.
It's quite likely that I misunderstand.  It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of

Linker doesn't segfault.

glibc.  The linker isn't like the compiler, where we tighten
restrictions on the input language.  The linker should accept old object
files.  And of course it should never segfault.  But if I misunderstand,
then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

[Ian Lance Taylor]

Post by H.J. Lu

It's quite likely that I misunderstand.  It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of

Linker doesn't segfault.

glibc.  The linker isn't like the compiler, where we tighten
restrictions on the input language.  The linker should accept old object
files.  And of course it should never segfault.  But if I misunderstand,
then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

Ian

[H.J. Lu]

Post by Ian Lance Taylor

Post by H.J. Lu

It's quite likely that I misunderstand.  It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of

Linker doesn't segfault.

glibc.  The linker isn't like the compiler, where we tighten
restrictions on the input language.  The linker should accept old object
files.  And of course it should never segfault.  But if I misunderstand,
then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

It happens at build-time and build won't finish. Hopefully, one won't
install an unfinished glibc build :-(.

[Mike Frysinger]

Post by H.J. Lu

Post by Ian Lance Taylor

Post by H.J. Lu

Post by Ian Lance Taylor
It's quite likely that I misunderstand. It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of

Linker doesn't segfault.

Post by Ian Lance Taylor
glibc. The linker isn't like the compiler, where we tighten
restrictions on the input language. The linker should accept old
object files. And of course it should never segfault. But if I
misunderstand, then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

It happens at build-time and build won't finish.

assuming native build. a cross-build wont have a clue.
-mike

[H.J. Lu]

Post by H.J. Lu

Post by Ian Lance Taylor

Post by H.J. Lu

It's quite likely that I misunderstand.  It sounds like you are saying
that it's OK for GNU ld to segfault when building an older version of

Linker doesn't segfault.

glibc.  The linker isn't like the compiler, where we tighten
restrictions on the input language.  The linker should accept old
object files.  And of course it should never segfault.  But if I
misunderstand, then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

It happens at build-time and build won't finish.

assuming native build.  a cross-build wont have a clue.

Well, you have to test your build.

[Mike Frysinger]

Post by H.J. Lu

Post by Mike Frysinger

Post by H.J. Lu

Post by Ian Lance Taylor

Post by H.J. Lu

Post by Ian Lance Taylor
It's quite likely that I misunderstand. It sounds like you are
saying that it's OK for GNU ld to segfault when building an older
version of Linker doesn't segfault.
glibc. The linker isn't like the compiler, where we tighten
restrictions on the input language. The linker should accept old
object files. And of course it should never segfault. But if I
misunderstand, then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

It happens at build-time and build won't finish.

assuming native build. a cross-build wont have a clue.

Well, you have to test your build.

yes, and when you test it, all you know is it segfaults. there is no "it
doesnt finish building" issue, and for the majority of people out there, they
wont have any idea. they'll just start googling for "glibc segfault" or try
random versions of the toolchain pieces until they get a component that works.
but i guess you really cant detect this change since it is done at the linker
script level. code that used to compile & link & run but now compiles & links
& silently segfaults sucks the most for end users. at least with a link time
warning they have a fighting chance of figuring things out.
-mike

[H.J. Lu]

Post by H.J. Lu

Post by H.J. Lu

Post by Ian Lance Taylor

Post by H.J. Lu

It's quite likely that I misunderstand.  It sounds like you are
saying that it's OK for GNU ld to segfault when building an older
version of Linker doesn't segfault.
glibc.  The linker isn't like the compiler, where we tighten
restrictions on the input language.  The linker should accept old
object files.  And of course it should never segfault.  But if I
misunderstand, then I apologize for raising the issue.

The problem is the linker generates bad libc.so with unfixed glibc.
The fix is trivial and leads to slightly better libc.so as extra bonus.

Thanks for the correction, but that's sort of worse.

It happens at build-time and build won't finish.

assuming native build.  a cross-build wont have a clue.

Well, you have to test your build.

yes, and when you test it, all you know is it segfaults.  there is no "it
doesnt finish building" issue, and for the majority of people out there, they
wont have any idea.  they'll just start googling for "glibc segfault" or try
random versions of the toolchain pieces until they get a component that works.
but i guess you really cant detect this change since it is done at the linker
script level.  code that used to compile & link & run but now compiles & links
& silently segfaults sucks the most for end users.  at least with a link time
warning they have a fighting chance of figuring things out.

If you are building glibc yourself, you should be on the glibc mailing list
and keep tracks of what is going on.

[Mike Frysinger]

Post by H.J. Lu

Post by Alan Modra
Do you think it is OK for a new GNU ld to without warning build older
versions of glibc that segfault at runtime?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not exactly, it segfault at build-time

while it may fail during `make`, it fails while executing the freshly compiled
local binaries. so yes, much of glibc was compiled, and then it segfaulted
while executing.

Post by H.J. Lu
If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

i think that would help out a lot of people

Post by H.J. Lu
I fixed the problem in glibc. .ctor isn't standard. All ELF C run-time
libraries should switch to .init_array anyway.

and how are they supposed to know that ? all people know now is that they
upgrade their binutils, rebuild things, and the result randomly segfaults. if
you're going to purpusefully link broken binaries, you need to warn people.
-mike

[H.J. Lu]

Post by Mike Frysinger

Post by H.J. Lu

Post by Alan Modra
Do you think it is OK for a new GNU ld to without warning build older
versions of glibc that segfault at runtime?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not exactly, it segfault at build-time

while it may fail during `make`, it fails while executing the freshly compiled
local binaries.  so yes, much of glibc was compiled, and then it segfaulted
while executing.

Post by H.J. Lu
If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

i think that would help out a lot of people

Please use commit 0bdbd36b52d7e46202701bb7e1658f4491e7c366
on hjl/release/2.12/x86 branch at

http://git.kernel.org/?p=devel/glibc/hjl/x86.git;a=summary

Post by Mike Frysinger

Post by H.J. Lu
I fixed the problem in glibc.  .ctor isn't standard. All ELF C run-time
libraries should switch to .init_array anyway.

and how are they supposed to know that ?  all people know now is that they
upgrade their binutils, rebuild things, and the result randomly segfaults.  if
you're going to purpusefully link broken binaries, you need to warn people.
-mike

I should have put a big warning in my binutils release note.

[Mike Frysinger]

Post by H.J. Lu

Post by Mike Frysinger

Post by H.J. Lu
If you want to use the latest
binutils to BUILD your glibc, I think it is OK to require you to patch
your glibc. I can provide a patch for glibc 2.12.

i think that would help out a lot of people

Please use commit 0bdbd36b52d7e46202701bb7e1658f4491e7c366
on hjl/release/2.12/x86 branch at
http://git.kernel.org/?p=devel/glibc/hjl/x86.git;a=summary

Andreas/Petr: could you grab this for glibc 2.11.x (if that's still being
done) and glibc 2.12.x ?
-mike