This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Binary compatibility between glibc 2.1.0/2.1.1 and 2.1.2 ?


>>>>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]