This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: shared library results in wrong function version
- To: Andreas Schultz <Schultz dot Andreas at tci dot com>
- Subject: Re: shared library results in wrong function version
- From: Andreas Jaeger <aj at suse dot de>
- Date: 16 Nov 1999 07:58:00 +0100
- Cc: glibc-linux list <glibc-linux at ricardo dot ecn dot wfu dot edu>
- References: <3830D3AE.14FC2AA8@tci.com>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
>>>>> Andreas Schultz writes:
> Hi,
> I noticed this problem with linuxthreads, but i may apply to other
> functions to.
> libpthreads has two version for a number of functions, e.g:
> nm /usr/lib/libpthread.so | grep sem_post
> 00008480 t __new_sem_post
> 000099a0 t __old_sem_post
> 00008480 T sem_post@@GLIBC_2.1
> 000099a0 T sem_post@GLIBC_2.0
> A program linked against this lib should now use the @@GLIBC_2.1
> version, resulting in
> a call to __new_sem_post. GDB however shows that __old_sem_post is
> called - resulting in
> a segfault.
> The static linked version of the program works flawless.
> enviroment:
> SuSE 6.2 upgraded with:
> Linux 2.3.25
> glibc-2.1.2
> gcc 2.95.2
> binutils 2.9.5.0.16
> I had the same problem with glibc 2.1.1
> The program uses a rather large shared library, which has ca. 10k
> symbols
> ldd micotest
> libmico2.3.0.so => /home/aschultz/mico/orb/libmico2.3.0.so
> (0x40014000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x404be000)
> librt.so.1 => /lib/librt.so.1 (0x404d1000)
> libdl.so.2 => /lib/libdl.so.2 (0x404d5000)
> libm.so.6 => /lib/libm.so.6 (0x404d9000)
> libc.so.6 => /lib/libc.so.6 (0x404f6000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> ls -l micotest
> -rwxr-xr-x 1 aschultz users 2358053 Nov 15 20:25 micotest
> ls -l /home/aschultz/mico/orb/libmico2.3.0.so
> -r-xr-xr-x 1 aschultz users 9637906 Nov 15 18:49
> /home/aschultz/mico/orb/libmico2.3.0.so
> The error is get:
> Program received signal SIGSEGV, Segmentation fault.
> sem_restart_list (waiting=0x0) at oldsemaphore.c:191
> 191 waiting = waiting->p_nextwaiting;
> Current language: auto; currently c
> (gdb) bt
> #0 sem_restart_list (waiting=0x0) at oldsemaphore.c:191
> #1 0x404c79fe in __old_sem_post (sem=0x806800c) at oldsemaphore.c:157
> #2 0x40280e32 in MICO::msg_queue::put_msg (this=0x8068000, nextOP_id=3,
> msg=0x40846ff4) at ../include/mico/os-thread/pthreads.h:107
> #3 0x4027f185 in MICO::thread_pool_manager::put_msg (this=0x8067f40,
> nextOP_id=3, msg=0x40846ff4) at mt_manager.cc:89
> #4 0x402797ca in MICO::Operation::send_msg (this=0x40840fe8,
> nextOP_id=3,
> msg=0x40846ff4) at Operation.cc:92
> *It should never call a function from oldsemaphore !!!!* right ????
Wrong. If libmico has been compiled against an older glibc, it uses
the older implementation. You've got to differentiate between
run-time linking and compile time linking. At compile time the
binding of sem_post is decided. I advise to recompile the mico libs.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de