This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Symbol versioning problem? Different versions of same symbol being called.
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.
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.
--
Carlo Wood <carlo@alinoe.com>