Serious regressions due to newlib's HAVE_INITFINI_ARRAY (Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237))

Ulrich Weigand
Wed Feb 22 19:21:00 GMT 2012

Jakub Jelinek wrote:

> 	PR bootstrap/50237
> 	* config/initfini-array.h: Guard content of the header
> 	with #ifdef HAVE_INITFINI_ARRAY.
> 	* Move gcc_AC_INITFINI_ARRAY much later into the file.
> 	Add initfini-array.h to tm_file here.
> 	* acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker
> 	test.
> 	* config.gcc: Don't add initfini-array.h to tm_file here.
> 	* configure: Regenerated.

This patch causes serious regressions on spu-elf, and presumably other
newlib targets.  The effect of the patch is to switch GCC to use
.init_array/.fini_array instead of .init/.fini; but the former is
not actually supported by newlib startup code (at least on SPU and
most other platforms supported by newlib), so that constructors and
destructors end up simply being ignored.

This occurs due to combination of GCC configury changes introduced
by the patch and a bug in newlib system headers.  Before the patch,
initfini-array.h was not included into tm.h when building a cross-
compiler to spu-elf, and after the patch it is.  Now, the patch
also inserts a #ifdef HAVE_INITFINI_ARRAY check, and the configure
check does not define this macro for cross-compilers, so in theory
that should not cause any change in behaviour.

However, the macro HAVE_INITFINI_ARRAY is defined anyway; this
definition is done by an internal "newlib.h" header that is pulled
in via the <stdio.h> include in GCC's "tsystem.h".  [ This is clearly
a violation of C namespace rules, but this has been the situation
for all newlib releases since about 2005 ... ]

Since initfini-array.h is now pulled in and HAVE_INITFINI_ARRAY
is defined, we get USE_INITFINI_ARRAY defined as well, which
causes the crtstuff files to be build for .init_array support.

Now, I guess the newlib headers should be fixed to no longer
pollute the namespace by defining HAVE_INITFINI_ARRAY.

However, I'm wondering whether there is a way to change
GCC to fix that regression even with existing newlib headers.

For example, I guess GCC configury could rename its instance of

Any suggestions how to proceed with this welcome!  I'd really
like to see this fixed for 4.7, otherwise the compiler will be
seriously broken ...


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

More information about the Newlib mailing list