Re: LSB wrapper library
I've noticed some flaws in my first tests from yesterday:
- libc.so is the only library that really needs the dynamic linker
(thanks Matt for pointing this out)
- The program I tested was linked against the normal lib and not with
the wrapper library.
Ok, another try, I have all libs set up as previous and compile a
simple test program:
gee:~/tmp:[0]$ gcc -Wall t.c -Wl,--dynamic-linker=/lib/ld-lsb.so.1
gee:~/tmp:[0]$ ./a.out
Test
gee:~/tmp:[0]$ ldd ./a.out
libc.so.6 => /lib/lsb/libc.so.6 (0x40019000)
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1 (0x40000000)
Everything looks fine so far.
Now I change ld-lsb.so.1 so that it points to ld-linux.so.2:
$ ls -l /lib/ld-lsb.so.1
lrwxrwxrwx 1 root root 13 Apr 4 16:12 /lib/ld-lsb.so.1 -> ld-linux.so.2
Everything still working as expected:
$ ldd ./a.out
libc.so.6 => /lib/libc.so.6 (0x40027000)
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1 (0x40000000)
gee:~/tmp:[0]$ ./a.out
Test
Ok, let's link my test program against libncurses and see what
happens:
gee:~/tmp:[0]$ ldd ./a.out
libncurses.so.5 => /lib/libncurses.so.5 (0x40027000)
libc.so.6 => /lib/libc.so.6 (0x40071000)
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1 (0x40000000)
gee:~/tmp:[0]$ ./a.out
Test
Now I'm changing ld-lsb.so.1 to point to the new lib:
$ ls -l /lib/ld-lsb.so.1
lrwxrwxrwx 1 root root 20 Apr 4 16:15 /lib/ld-lsb.so.1 -> /lib/lsb/ld-lsb.so.1
gee:~/tmp:[0]$ ./a.out
./a.out: error while loading shared libraries: libncurses.so.5: cannot load shared object file: No such file or directory
Ok, I create a link for libncurses
$ ls -l /lib/lsb/libncurses.so.5
lrwxrwxrwx 1 root root 18 Apr 4 16:16 /lib/lsb/libncurses.so.5 -> ../libncurses.so.5
and now everything looks fine:
gee:~/tmp:[0]$ ldd ./a.out
libncurses.so.5 => /lib/lsb/libncurses.so.5 (0x40019000)
libc.so.6 => /lib/lsb/libc.so.6 (0x40064000)
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1 (0x40000000)
gee:~/tmp:[0]$ ./a.out
Test
And the test from yesterday:
gee:/cvs/libc:[0]$ LD_PRELOAD=libncurses.so.5 ~/tmp/a.out
Test
works fine now.
If I remove libc.so.6 from /lib/lsb and create a link:
$ ls -l /lib/lsb/libc.so.6
lrwxrwxrwx 1 root root 12 Apr 4 16:17 /lib/lsb/libc.so.6 -> ../libc.so.6
I get problems:
$ ldd ./a.out
libncurses.so.5 => /lib/lsb/libncurses.so.5 (0x40019000)
libc.so.6 => /lib/lsb/libc.so.6 (0x40064000)
ld-linux.so.2 => not found
Let's summarize what this little playing showed together with some
other facts:
- there's no need to filter out ld-linux.so.2 if you have a copy of
libc.so
- ld.so and libc.so have to be the same version. You're not allowed
to use them from different glibc version. Therefore if there's a reason
to split we should create both ld.so and libc.so.
- It's easy to link a library in. libncurses was build against my
normal glibc and it worked fine with the LSB setup.
So, everything should be fine or what kind of problems do you see now?
Andreas
P.S. Looking at all this, it might have been wiser to use new sonames
for all libraries. In that case we would split directly - but it
would be totally clear which lib is used and which not. Not changing
the soname might cause pains if something goes wrong (is really the
right library used? which libc.so.6 is this - the LSB or the normal
one?)
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: