Re: libdl bugs

Hello,

Subject: libdl bugs
Date: Thu 18.02.2010
Quoting Markus Wichmann ([email protected]):
>I don't know, since you don't have a bug tracker, but it could be this
>problem already got reported. According to the changelog, work on the
>libdl ceased in 2007.

Sadly I hadn't much time since.

>The libdl has a bug causing it to crash with signal 11. The cause is line
>803 of _dl_main.c: You are accessing a structure without checking the
>contents beforehand.

A check whould be a sensible thing to do. But why would there be anything
NOT complying with the ELF-structure in an ELF-file?

>Any program linked dynamically against dietlibc has a DT_NEEDED entry for
>"libc.so". Now my distributor (Debian) ships a linker script called
>/usr/lib/libc.so. Certainly with the best of intentions, just that the
>dietlibc's libdl crashes when trying to open it.

Ah! If that file is considered you have done something wrong.

First of all, is the file "/etc/diet.ld.conf" correctly installed?
In it should be a path to the diet-libraries, e.g.:
	/opt/diet/lib-i386

You can also specify other dietlibc dynamic library directories in it.

Second, dynamically linked is sadly not meaning that one could use the
dynamic libraries compiled with glibc headers. Conclusion of that is:
_every_ library you want to use with the dynamic-dietlibc has to be compiled
anew.

Third, make sure you have no library or include path (-L/-I ...) in your
Makefile pointing to anything not compiled with dietlibc.
This is the toughest thing to do, since _libtool_ doesn't care much about
libraries that doesn't provide a 'libtool-library' (a.k.a. *.la).
And these files have a full pathname in them. If libtool is used you have
some work to do by hand.

>A simple fix would be to check if the ELF header has got the magic and
>class right (multilib systems do exist) and ignore the file if it doesn't.
>I would fix it myself, just that the libdl is a bunch of functions calling
>each other, I don't know, where to insert the fix. Currently, I put it at
>line 803 of _dl_main.c, the action being "goto err_out_close", which is
>the label put where the action of a failing stat() on the file is.

Header check could work for an early abbort, as said. On the other hand at
the time I had started to look into dynamic linking, I went with the premise
that a library should alway have their name correct.
Linker-scripts should be in a seperate, not in the standard lib-path.

>Oh, and another thing: The libdl loads files based solely on their file
>name. DT_NEEDED entries, on the other hand, may contain the libraries'
>DT_SONAME. Now the glibc features "ldconfig" that symlinks the DT_SONAME
>of all the libraries to the file name. Basically, dietlibc would need

Same as above. Why should the library want to have a different name than
with which it was installed? Besides the installer should create all the
symlinks needed.
If you want to write a 'ldconfig' that creates the symlinks based on the
DT_SONAME, be our guest. But I hadn't had any library that didn't installed
the correct symlinks as well.

>a) something similar, introducing the need for a post library install
>program run, during which the file system has to be mounted read/write.
>And the possibility of malfunction due to failure to run said program.
>
>or
>
>b) to look, upon looking for the library, into each file, to see if the
>soname equals the needed name. That would mean, for each call to dlopen(),
>the dynlinker would need to open every ordinary file in the search paths
>and parse a bit of them. But(!) there would be zero possibility of stale
>files.

As said. Install the libraries correctly and there is no need for the post
install program. And also said, the library should have the correct
filesystem name.
Both are easier than bloat up the library search. Even if the dynamic
handling is bloat in and of itself. ;)

Best regards,
  Olaf

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!