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

[Carlo Wood]

I tracked down a bug to be a mixup of __old_sem_post and
__new_sem_post being called in the same application.
I am not sure if this is a bug of g++ or binutils.
Details are below.

In a C++ template, and thus in a header file, I have
defined a function that calls the glibc function `sem_post'.
This header file is part of a shared library.
The library is compiled as follows (as per libtool):

~/c++/libcw/src/libcwd>g++-3.0.3 -DHAVE_CONFIG_H -I./include -I./include 
-DCWDEBUG -ggdb3 -pthread -Wall -Woverloaded-virtual -Wundef -Wpointer-arith 
-Wwrite-strings -Werror -Winline -c debugmalloc.cc -MT debugmalloc.lo -MD -MP 
-MF .deps/debugmalloc.TPlo  -fPIC -DPIC -o debugmalloc.o -v -save-temps
Reading specs from 
/usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
Configured with: /usr/src/gcc/gcc-3.0.3/configure --prefix=/usr/local/gcc-3.0.3 
--enable-shared --with-gnu-as --with-gnu-ld --enable-languages=c++ 
--enable-debug --enable-threads
Thread model: posix
gcc version 3.0.3
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c++ 
-D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v 
-I./include -I./include -M -MF debugmalloc.d -MF .deps/debugmalloc.TPlo -MP -MT 
debugmalloc.lo -MQ debugmalloc.o -D__GNUC__=3 -D__GNUC_MINOR__=0 
-D__GNUC_PATCHLEVEL__=3 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ 
-D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ 
-D__STDC_HOSTED__=1 -Wall -Woverloaded-virtual -Wundef -Wpointer-arith 
-Wwrite-strings -Werror -Winline -D_GNU_SOURCE -Acpu=i386 -Amachine=i386
-Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D__PIC__ 
-D__pic__ -D_REENTRANT -DHAVE_CONFIG_H -DCWDEBUG -DPIC debugmalloc.cc 
debugmalloc.ii
GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory "/usr/local/gcc-3.0.3/i686-pc-linux-gnu/include"
ignoring duplicate directory "include"
#include "..." search starts here:
#include <...> search starts here:
 include
 /usr/local/gcc-3.0.3/include/g++-v3
 /usr/local/gcc-3.0.3/include/g++-v3/i686-pc-linux-gnu
 /usr/local/gcc-3.0.3/include/g++-v3/backward
 /usr/local/include
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include
 /usr/include
End of search list.
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cc1plus 
-fpreprocessed debugmalloc.ii -quiet -dumpbase debugmalloc.cc -ggdb3 -Wall 
-Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -Winline 
-version -fPIC -o debugmalloc.s
GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.3 (i686-pc-linux-gnu)
        compiled by GNU C version 3.0.3.
 as --traditional-format -V -Qy -o debugmalloc.o debugmalloc.s
GNU assembler version 2.11.92.0.12.3 (i386-redhat-linux) using BFD version 
2.11.92.0.12.3 20011121

After which 'debugmalloc.s' contains the assembly:

        call    address@hidden

This results in assembly (disassembled with gdb):

        call   0x400672f0 <_init+8040>

An application that uses this library is compiled as follows:

~/c++/libcw/src/libcwd/tests>g++-3.0.3 -DHAVE_CONFIG_H  -I. -I../include 
-I./../include    -DCWDEBUG -ggdb3  -pipe -pthread -Wall -Woverloaded-virtual 
-Wundef -Wpointer-arith -Wwrite-strings -Werror -Winline -c -o threads4.o 
threads4.cc -v -save-temps
g++: Warning: -pipe ignored because -save-temps specified
Reading specs from 
/usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
Configured with: /usr/src/gcc/gcc-3.0.3/configure --prefix=/usr/local/gcc-3.0.3 
--enable-shared --with-gnu-as --with-gnu-ld --enable-languages=c++ 
--enable-debug --enable-threads
Thread model: posix
gcc version 3.0.3
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cpp0 -lang-c++ 
-D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -I. 
-I../include -I./../include -D__GNUC__=3 -D__GNUC_MINOR__=0 
-D__GNUC_PATCHLEVEL__=3 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ 
-D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ 
-D__STDC_HOSTED__=1 -Wall -Woverloaded-virtual -Wundef -Wpointer-arith 
-Wwrite-strings -Werror -Winline -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 
-D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D_REENTRANT 
-DHAVE_CONFIG_H -DCWDEBUG threads4.cc threads4.ii
GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory "/usr/local/gcc-3.0.3/i686-pc-linux-gnu/include"
ignoring duplicate directory "../include"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../include
 /usr/local/gcc-3.0.3/include/g++-v3
 /usr/local/gcc-3.0.3/include/g++-v3/i686-pc-linux-gnu
 /usr/local/gcc-3.0.3/include/g++-v3/backward
 /usr/local/include
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/include
 /usr/include
End of search list.
 /usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cc1plus 
-fpreprocessed threads4.ii -quiet -dumpbase threads4.cc -ggdb3 -Wall 
-Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -Winline 
-version -o threads4.s
GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.3 (i686-pc-linux-gnu)
        compiled by GNU C version 3.0.3.
 as --traditional-format -V -Qy -o threads4.o threads4.s
GNU assembler version 2.11.92.0.12.3 (i386-redhat-linux) using BFD version 
2.11.92.0.12.3 20011121

After which 'threads4.s' contains the assembly:

        call    sem_post

This results in assembly (disassembled with gdb):

        call   0x804c970 <sem_post>

When stepping into these respective calls it turn out
that the first calls:

Breakpoint 4, libcw::debug::_private_::rwlock_tct<11>::wrunlock() () at 
include/libcw/private_threading.h:505
505             sem_post(&S_no_readers_left);
(gdb) s
__old_sem_post (sem=0x8055118) at oldsemaphore.c:174

While the second calls:

Breakpoint 1, libcw::debug::_private_::rwlock_tct<11>::rdunlock() () at 
../include/libcw/private_threading.h:455
455             sem_post(&S_no_readers_left);
(gdb) s
__new_sem_post (sem=0x8055118) at internals.h:380


Obviously, using two versions of the same functions leads
to "undefined" behaviour (it hangs).

If anyone can give me any clues on how to work around
this bug temporarily then please tell me!

-- 
Carlo Wood <address@hidden>

PS CC to address@hidden because I don't know _where_ the bug actually is.
PS Environment: glibc-2.2.4