[Bug ld/15025] --enable-initfini-array creates .init_array where no input has one

[rguenther at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=15025

--- Comment #2 from rguenther at suse dot de 2013-01-18 09:30:58 UTC ---
It breaks building glibc for example.

What's the technical reason to force this change at link-time whenever
ld.so on the build system supported .init_array?

The only reason I can see is for input files that mix .ctor.N and
.init_array.N - for correctness you need to merge them.  But merging
.ctors into .init_array is not required for anything.

So, why is this not at least

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

thus not put .ctors (minus crtfiles??!!!) in .init_array.

It still will rewrite all-.ctor.N inputs to .init_array which I consider
broken, too.  But I'm not sure one can conditionalize .init_array output
on .init_array input section presence in the linker script.

This bug forces us to use --disable-initfini-array which breaks mixed
.ctor.N / .init_array.N input file support (which was the whole point
of the excercise).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.