Re: Task 23709
gk4@us.ibm.com writes:
> Andreas,
>
> Your examples and summary clarifies the setup of the LSB's wrapper
> methodology very well.
>
> http://lists.debian.org/lsb-discuss-0104/msg00025.html
>
> Would it be possible for you to write something with more explanations and
> rationale for the casual reader?
What about the appended version?
Andreas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The LSB Wrapper Library
The current LSB draft gives distributors two options to implement the
LSB dynamic linker and the choice to switch between those solutions:
- Install a link from /lib/ld-linux.so.2 (my examples come from
Linux/i386, for other architectures some names might be different)
to /lib/ld-lsb.so.1
- Install a new dynamic linker /lib/ld-lsb.so.1
If your system's base libraries are conforming to the LSB, the link
might be the right choice. Alternativly you can install a real linker
and also add system libraries so that they will be found by the
ld-lsb.so.1.
All LSB compliant binaries will be linked against /lib/ld-lsb.so.1.
I've run some simple tests to check that this switch works and that
glibc handles a real /lib/ld-lsb.so.1.
I build glibc 2.2.3 with the following configure line:
/cvs/libc-lsb/configure --prefix=/opt/lsb --enable-add-ons \
--disable-profile --without-cvs
and then created a configparms file in the build directory:
$ cat configparms
slibdir=/lib/lsb
rtld-installed-name=ld-lsb.so.1
config-LDFLAGS = -Wl,-dynamic-linker=/lib/ld-lsb.so.1
make install installed all the libraries in the right place with the
exception of /lib/ld-lsb.so.1, I just had to add a link from
/lib/lsb/ld-2.2.3.so to /lib/ld-lsb.so.1.
This glibc setup should work in case that we fork. But if we fork we
do need to fork **all** LSB libraries.
Everything seems to work fine, e.g.:
$ ldd /opt/lsb/bin/getconf
libc.so.6 => /lib/lsb/libc.so.6 (0x40019000)
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1 (0x40000000)
IMO ld-lsb.so.1 should *not* look into /lib and /usr/lib, no library
should live there. We should keep the namespaces really separate.
I used /opt/lsb (this can be changed) so that the lsb libs find their
config files and environment in a specified place. If we fork, we
really need not only separate libs but also separate locale files and
gconv modules - everything that gets compiled can not be shared.
Certainly some files can be shared but let's keep it easy for now.
Note that libc.so is linked against the dynamic linker. If
ld-lsb.so.1 is a real program, you need to add libc.so and link it
against ld-lsb.so.1.
Let's compile a simple "Hello World" 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
This is to be expected since the new dynamic linker does not look into
/lib and /usr/lib.
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
Preloading of libs also works:
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 Jaeger <aj@suse.de>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: