Bug 2672 - going libc_pic.a to libc_pic.os discard gets into the way
Summary: going libc_pic.a to libc_pic.os discard gets into the way
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.4
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-17 18:00 UTC by Rainer Malitzke Goes
Modified: 2019-04-10 08:17 UTC (History)
2 users (show)

See Also:
Host: powerpc
Target: powerpc
Build: powerpc
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Malitzke Goes 2006-05-17 18:00:18 UTC
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
Comment 1 Rainer Malitzke Goes 2006-05-17 18:04:18 UTC
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.
Comment 2 Dwayne Grant McConnell 2006-05-17 18:41:58 UTC

*** This bug has been marked as a duplicate of 333 ***
Comment 3 Andrew Pinski 2006-08-04 02:39:13 UTC
Actually this is stupid not to be able to report build errors to bugzilla.
Comment 4 Andrew Pinski 2006-08-04 02:39:41 UTC
Second this has now since been reported upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28598
Comment 5 Andrew Pinski 2006-08-04 15:21:18 UTC
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.
Comment 6 Andrew Pinski 2006-08-10 06:17:00 UTC
And this is a real glibc bug.
Comment 8 Ulrich Drepper 2006-08-24 06:58:32 UTC
This is a stupidity in gcc which has been worked around in glibc for some time now.
Comment 9 Jackie Rosen 2014-02-16 19:32:54 UTC Comment hidden (spam)