Re: LSB wrapper library

[Andreas Jaeger <aj@suse.de>]

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