This is the mail archive of the
mailing list for the binutils project.
Re: differences in generated ldscripts for native and cross builds
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: amodra at gmail dot com (Alan Modra)
- Cc: thomas at codesourcery dot com (Thomas Schwinge), joseph at codesourcery dot com (Joseph Myers), hjl dot tools at gmail dot com (H.J. Lu), doko at debian dot org (Matthias Klose), binutils at sourceware dot org (binutils)
- Date: Tue, 8 Dec 2015 18:06:44 +0100 (CET)
- Subject: Re: differences in generated ldscripts for native and cross builds
- Authentication-results: sourceware.org; auth=none
Alan Modra wrote:
> On Sun, Dec 06, 2015 at 09:00:41PM +0100, Thomas Schwinge wrote:
> > On Wed, 2 Dec 2015 19:29:51 +1030, Alan Modra <email@example.com> wrote:
> > > I think it's time we defaulted to --enable-initfini-array, at least for
> > > binutils-2.27.
> > Makes sense to me (only for systems where it's supported, of course).
> The macros defined by --enable-initfini-array are HAVE_INITFINI_ARRAY,
> which is only used by ld/testsuite/ld-elf/init-mixed.c, and
> ENABLE_INITFINI_ARRAY, which is used in ld/scripttempl/nds32elf.sc,
> ld/scripttempl/elf.sc, and ld/emulparams/elf_nacl.sh. Thus we don't
> need anything target specific in configure.ac: Non-ELF targets won't
> be affected by the change.
> Where we might get into trouble is on systems that use old startup
> files lacking code to call constructor function pointers in
> .init_array. For glibc that means 2002 vintage code, I think.
I just noticed this change broke spu-elf; most newlib targets (with
the sole exception of ARM/AArch64) still do not support .init_array.
But I guess at this point I can live with having to specify
--disable-initfini-array when building current binutils for SPU ...
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain