http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #38 from philip.copeland at oracle dot com 2013-01-12 14:10:52 UTC --- Ugh,... well, the good news is that I can now compile this successfully. I didn't even need to rebuild gcc. (although I will just to follow through on Eric's suggestion since I didn't find anything terrifically useful as a test for the initfini-array elf header sections) Fedora's glibc does not specifically pass --with-tls, and it is assumed that this is automatically picked up by the configure script (it isn't but I need to examine that as to why a bit later) By forcing --with-tls through the configure script and reinstalling the glibc, g++ seems to notice glibc supporting tls and generates the code necessary for it. The rebuilt gcc-4.7.2-8 without initfini-array support produces the same testsuite results as previously mentioned in #c10 and #c12 + CC=/builddir/build/BUILD/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/gcc64 + CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultrasparc' ++ echo -O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultrasparc ++ sed 's/ -Wall / /g' + CXXFLAGS='-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultrasparc' + XCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultrasparc ' + TCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultrasparc ' + GCJFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mcpu=ultraspar c' + ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128 --with-cpu=ultrasparc --disable-multilib --disable-initfini-array --build=sparc64-redhat-linux <just in case there was some discrepancy with what was passed into configure and what got built..> <mock-chroot>[root@localhost ~]# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper Target: sparc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128 --with-cpu=ultrasparc --disable-multilib --disable-initfini-array --build=sparc64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) <mock-chroot>[root@localhost tmp]# g++ test.c -o test <mock-chroot>[root@localhost tmp]# ./test we are able to write to stderr <mock-chroot>[root@localhost tmp]# also works however,.. <mock-chroot>[root@localhost tmp]# readelf -S ./test | egrep "init|fini|array" [11] .init PROGBITS 0000000000100628 00000628 [13] .fini PROGBITS 0000000000100b60 00000b60 [17] .init_array INIT_ARRAY 0000000000200c78 00000c78 .init_array somehow crept into binary despite being specifically disabled. I dunno if that was supposed to happen but it hasn't shown any ill effect as yet So my last thoughts are, what exactly do we loose by not supporting initfini_array on sparc? -------------------------------------------------------------------------------- (From various googled sources and the gnu install.texi file): .init_array An array of function pointers that contributes to a single initialization array for the executable or shared object containing the section. .fini_array An array of function pointers that contribute to a single termination array for the executable or shared object containing the section." --enable-initfini-array Force the use of sections {.init_array} and {.fini_array} (instead of {.init} and {.fini}) for constructors and destructors. Option {--disable-initfini-array} has the opposite effect. If neither option is specified, the configure script will try to guess whether the {.init_array} and {.fini_array} sections are supported and, if they are, use them. -------------------------------------------------------------------------------- My reading of this is that .fini and .init will do just fine but only support one function whereas the *_array sections can store numerous functions. I'm guessing this is a load efficiency saver for the linker but wouldn't affect normal program execution speed?
