This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu
On Fri, Aug 09, 2002 at 08:55:37PM +0200, Franz Sirl wrote:
> On Mittwoch, 7. August 2002 19:16, Franz Sirl wrote:
> > So what happened? I think we are hosed, cause we violated Uli's "Golden
> > Rule" for version scripts on Linux: "On Linux, don't use a version script
> > to attach versions to symbols, only use it to decide if a symbol
> > pre-versioned with .symver should be local or global."
> > Cause libgcc_s is linked against glibc, the linker decides to leave the
> > divmod functions in libgcc_s local, because they already exist with the
> > same version and global in glibc.
This is not how the linker works.
When building libgcc_s, -lc comes after all the libgcc/./*{div,mod}di3.o
which means the symbols are exported from both glibc and
libgcc_s (with the same version):
On IA-32 where gcc has been built a couple of times since that glibc was
installed:
$ readelf -s /lib/libc.so.6 | grep moddi3
701: 00016ad0 55 FUNC GLOBAL DEFAULT 11 __umoddi3@@GLIBC_2.0
1856: 00016a10 128 FUNC GLOBAL DEFAULT 11 __moddi3@@GLIBC_2.0
$ readelf -s /lib/libgcc_s.so.1 | grep moddi3
46: 00002788 38 FUNC GLOBAL DEFAULT 11 __umoddi3@@GLIBC_2.0
95: 000021c0 240 FUNC GLOBAL DEFAULT 11 __moddi3@@GLIBC_2.0
So either you run into yet another linker bug, or you have
some pieces of your patch applied to the gcc tree you were testing.
>
> > Now lets see what options we have on PPC:
> >
> > 1. do nothing:
> > This leaves use with linktime version for the divmod functions in both
> > glibc and libgcc_s, which everybody seems to agree that this is a bad
> > idea.
#1 seems like the preferred choice when the symbol versions are identical
IMNSHO.
Jakub