This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [wiget@pld.org.pl] libc/3237: symbol __udivdi3, version GLIBC_2.0 not defined in file libc.so.6 with link time reference


On Mon, Apr 15, 2002 at 11:42:52AM +0200, Franz Sirl wrote:
> With gcc-2.95 this pulls in __umoddi3 and __udivdi3 from libgcc.a (and in 
> 2.95 these symbols are not tagged with .hidden) and then re-exports them 
> (which seems to be a perfectly normal thing for ld to do, if I'm 
> interpreting the docs correctly).
> 
> With gcc-3.1 these symbols are tagged with .hidden in libgcc.a and thus ld 
> does not re-export them.
> 
> Does this sound like a correct analysis? What shall we do here? Add the 
> libgcc symbols to glibc as Jakub suggested or change the way gcc-3.1 builds 
> libgcc.a?

This was a latent problem on all arches which did not export these
routines from libc. Programs/libraries could just stop working if a library
they depended on was upgraded/recompiled and did not need some
of those routines internally any more (like e.g. if gcc optimized out some
division or modulo).
.hidden was added to libgcc.a specifically so that this problem won't be
with us forever. If the routines aren't added as non-default version
to libc, it just means there is a binary compatibility thick line between
pre-gcc3.1 and gcc3.1+ shared libraries and since gcc3.1+ compiled
shared libraries this problem won't occur ever again.
My personal choice would be to add those as non-default versions to libc
on arches with large enough installed base (especially ppc and ia64), though
the decision is on Ulrich.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]