It looks to me that gcc is more incidental here and that really binutils is doing the work gcc -nostdlib -nostartfiles -r -o /usr/src/glibc-23/build/libc_pic.os -Wl,-d -Wl,--whole-archive /usr/src/glibc-23/build/libc_pic.a .LANCHOR0' referenced in section `.text' of /usr/src/glibc-23/build/libc_pic.a(strtoul_l.os): defined in discarded section `.gnu.linkonce.r.__strtol_ul_max_tab' of collect2: ld returned 1 exit status make[1]: *** [/usr/src/glibc-23/build/libc_pic.os] Error 1 make[1]: Leaving directory `/usr/src/glibc-23/glibc-2.3.7' make: *** [all] Error 2
Again I had to edit the part of the build output to from the redhat end of buzilla staying in a wait mode. It appears that there is excess of caution against people trying to slip something in. I had no trouble on gcc.gnu.org with similar stuff.
*** This bug has been marked as a duplicate of 333 ***
Actually this is stupid not to be able to report build errors to bugzilla.
Second this has now since been reported upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28598
I think this is a glibc now (from the gcc bug): const unsigned long __strtol_ul_max_tab[] __attribute__ ((visibility ("hidden"))) __attribute__((section(".gnu.linkonce.r." "__strtol_ul_max_tab"))) const unsigned char __strtol_ul_rem_tab[] __attribute__ ((visibility ("hidden"))) __attribute__((section(".gnu.linkonce.r." "__strtol_ul_rem_tab"))) They are explictly put into a linkonce section which really does not tell the compiler that. Also since const puts it be local to the TU, it gets even worse.
And this is a real glibc bug.
http://sourceware.org/ml/binutils/2006-08/msg00046.html
This is a stupidity in gcc which has been worked around in glibc for some time now.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.