Re: Symbol versioning problem? Different versions of same symbol being called.

[Carlo Wood]

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 address@hidden is being called.
The latter is the problem/bug.

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, address@hidden" causes
   the application to call the old version too.
   Using ".symver sem_post, address@hidden" causes
   'nm' to show undefined 'address@hidden' but it
   still calls "address@hidden".

The problem seems to be the use of 'call address@hidden' 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.

-- 
Carlo Wood <address@hidden>