This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Binary compatibility between glibc 2.1.0/2.1.1 and 2.1.2 ?
- To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
- Subject: Re: Binary compatibility between glibc 2.1.0/2.1.1 and 2.1.2 ?
- From: Juergen Kreileder <kreilede@issan.cs.uni-dortmund.de>
- Date: 05 Sep 1999 20:15:19 +0200
- Cc: libc-alpha@sourceware.cygnus.com
- Organization: Blackdown Java-Linux Porting Team
- References: <u8iu5pjmh1.fsf@arthur.rhein-neckar.de>
>>>>> Andreas Jaeger writes:
Andreas> So, my questions are:
Andreas> - does every library compiled for glibc 2.1.2 work for
Andreas> 2.1.1 and 2.1?
Andreas> - does every binary linked against libraries from glibc
Andreas> 2.1.2 and libraries linked against glibc 2.1.2 run on a
Andreas> glibc 2.1 and 2.1.1 system?
This doesn't work, e.g. if a binary/library needs sem_wait@@GLIBC_2.1
it won't run with glibc 2.1/2.1.1.
Andreas> - the other way round: does every library compiled for
Andreas> 2.1.1 and 2.1 work with 2.1.2?
I think it works at runtime but there can be problems if you try link
against such libraries.
I have one report about about problems with the Java Invocation API.
The user tried link his binary against a library from the JDK (built
with glibc 2.1) on a glibc-2.1.2pre3 system. He got this error
message:
/usr/lib/jdk1.1/lib/i386/native_threads/libjava.so: undefined reference to `sem_destroy@@GLIBC_2.0'
/usr/lib/jdk1.1/lib/i386/native_threads/libjava.so: undefined reference to `sem_post@@GLIBC_2.0'
/usr/lib/jdk1.1/lib/i386/native_threads/libjava.so: undefined reference to `sem_wait@@GLIBC_2.0'
/usr/lib/jdk1.1/lib/i386/native_threads/libjava.so: undefined reference to `sem_init@@GLIBC_2.0'
collect2: ld returned 1 exit status
IMHO this should work because the GLIBC_2.0 versions are available.
Here's a short example that demonstrates the problem without the need
for two different glibc versions and the JDK.
The example creates libmydummy.so, this library contains
'dummy@@VERS_1.1'. Later this library will be replaced with a library
that contains 'dummy@VERS_1.1' and 'dummy@@VERS_2.1'.
Then there is a library that references 'dummy', it is linked when
VERS_1.1 is the default.
Finally, there is a binary 'test'. I only can link this binary when
VERS_1.1 is the default.
$ cat mydummy.c
__asm__(".symver mydummy11,dummy@@VERS_1.1");
void mydummy11(void) {}
$ cat mydummy.map
VERS_1.1 {
dummy;
};
$ gcc -shared -o libmydummy.so -Wl,--version-script,mydummy.map mydummy.c -ldl -lc
$ nm libmydummy.so | grep dummy
00000580 T dummy@@VERS_1.1
00000518 t fini_dummy
00000530 t frame_dummy
00000568 t init_dummy
000005c4 t init_dummy
00000580 T mydummy11
$ gcc -shared -o libtest.so libtest.c -L . -lmydummy -ldl -lc
$ nm libtest.so | grep dummy
U dummy@@VERS_1.1
00000508 t fini_dummy
00000520 t frame_dummy
00000558 t init_dummy
000005b4 t init_dummy
$ cat test.c
main()
{
mytest();
}
$ gcc -o test test.c -L . -ltest -lmydummy
$ # OK so far, now libmydummy.so will be replaced
$ cat mydummy2.c
__asm__(".symver mydummy11,dummy@VERS_1.1");
__asm__(".symver mydummy12,dummy@@VERS_1.2");
void mydummy11(void) {}
void mydummy12(void) {}
$ cat mydummy2.map
VERS_1.1 {
dummy;
};
VERS_1.2 {
} VERS_1.1;
$ gcc -shared -o libmydummy.so -Wl,--version-script,mydummy2.map mydummy2.c -ldl -lc
$ nm libmydummy.so | grep dummy
000005f8 T dummy@@VERS_1.2
000005f0 T dummy@VERS_1.1
00000588 t fini_dummy
000005a0 t frame_dummy
000005d8 t init_dummy
00000634 t init_dummy
000005f0 T mydummy11
000005f8 T mydummy12
$ # libtest.so is unchanged, now try to link 'test' again
$ gcc -o test test.c -L . -ltest -lmydummy
./libtest.so: undefined reference to `dummy@@VERS_1.1'
collect2: ld returned 1 exit status
Shouldn't this work?
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Porting Team
http://www.blackdown.org/java-linux.html