This is the mail archive of the
mailing list for the glibc project.
Re: Symbol versioning problem? Different versions of same symbol being called.
- From: "H . J . Lu" <hjl at lucon dot org>
- To: Carlo Wood <carlo at alinoe dot com>
- Cc: GNU C Library <libc-alpha at sources dot redhat dot com>,binutils at sources dot redhat dot com
- Date: Thu, 24 Jan 2002 09:36:49 -0800
- Subject: Re: Symbol versioning problem? Different versions of same symbol being called.
- References: <20020124013408.A7683@alinoe.com> <20020124113641.GY16187@bubble.sa.bigpond.net.au> <20020124150030.A27421@alinoe.com>
On Thu, Jan 24, 2002 at 03:00:30PM +0100, Carlo Wood wrote:
> On Thu, Jan 24, 2002 at 10:06:41PM +1030, Alan Modra wrote:
> > On Thu, Jan 24, 2002 at 01:34:08AM +0100, Carlo Wood wrote:
> > > I tracked down a bug to be a mixup of __old_sem_post and
> > > __new_sem_post being called in the same application.
> > Use readelf to dump symbols. Is the application sem_post global?
> > Does the shared lib dynamic sem_post have default symbol
> > visibility? If both of these conditions are true, then your
> > shared lib ought to be calling the application sem_post.
> I've spend another day on hacking this bug, and it
> definitely is a bug of either binutils or maybe glibc.
> Reading your remark it seems that I've been unclear about
> what is happening. Let me explain it below.
> sem_post is defined in libpthread (part of glibc) and ONLY
> there. My shared library and application only call sem_post.
> glibc 2.4.4 exports the sem_* functions with versioning.
> The default version is set to "@@GLIBC_2.1" but it also
> contains a backward compatibility version "@GLIBC_2.0".
> When I compile a normal application that *uses* (for example)
> sem_post, then the correct default sem_post (sem_post@@GLIBC_2.1)
> is being called. However, when I compile the same code
> as a shared library, then sem_post@GLIBC_2.0 is being called.
> The latter is the problem/bug.
Is your shared library built with
# gcc/g++ -shared ....
> In the meantime I also tried what happens when:
> 1) I compiled the library as a static library and link with that:
> then sem_post@@GLIBC_2.1 is being called.
> 2) When I downgrade to binutils-2.10:
> nothing changes, the shared library still calls the wrong
> 3) When I force a version on the symbol using .symver:
> Using ".symver sem_post, sem_post@GLIBC_2.0" causes
> the application to call the old version too.
> Using ".symver sem_post, sem_post@GLIBC_2.1" causes
> 'nm' to show undefined 'sem_post@GLIBC_2.1' but it
> still calls "sem_post@GLIBC_2.0".
> The problem seems to be the use of 'call sem_post@PLT' in
> the assembly output of the shared library, that appear to
> be broken, not calling the default version anymore.
> As it is, it is impossible to call the default sem_post
> (sem_post@@GLIBC_2.1) from a shared library.
It works for me as long as I use "gcc -shared" to build the shared