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: Symbol versioning problem? Different versions of same symbol being called.


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
>    version.
> 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
library.


H.J.


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