Re: libdl bugs

Olaf Dreesen wrote:
> Hello,
>
> Subject: libdl bugs
> Date: Thu 18.02.2010
> Quoting Markus Wichmann ([email protected]):
>>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?
>

Not everything that has the file name of an ELF file is an ELF file.

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

Why that? Well written software should not crash no matter the circumstances.

Besides this bug is keeping the temporary diet-dyn compiled into
pic-x86_64 from working.

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

Oh wait, you want to cover up a bug by saying that if all is installed
well, it does not occur? The libdl considering a non-ELF file to be an ELF
file is at fault. Besides I did not install the dietlibc up until now,
because the libm has yet to be completed for my architecture (x86_64). So
I just built it to test my newly written math routines in dynamic context.

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

I know that already. I even tried to build an LFS-like system based on
dietlibc. Only problem was, though, that the build of gcc against dietlibc
failed due to an undefined reference to "log()" (no, not contained in
libm. Working on it.)

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

libtool? Who would need that? dietlibc is meant primarily for use with
linux, and for linux _any_ linker I know is called "ld", be it GNU ld or
GNU gold or whatever.

Really, I never knew what I would need libtool for. Most of the
abstraction is done by the compiler already

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

So, basically, you consider everything in the standard library paths that
conforms to the naming convention to be an ELF shared object.

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

To ease patch distribution, maybe? You can have a file "libXft.so.6.2"
with a soname of "libXft.so.6". Now, all applications should link to
"libXft.so.6". If there is a new release that would increase the minor
version number, a new lib would be installed called "libXft.so.6.3". And
still with a soname of "libXft.so.6", causing all applications using that
lib to use the new lib.

> Besides the installer should create all the
> symlinks needed.

Some do, some call ldconfig in hope that will do it

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

Oh, I already did. It's a shell script using readelf and ln.

> Both are easier than bloat up the library search. Even if the dynamic
> handling is bloat in and of itself. ;)
>

Oh, it has its good points: If there is a bug in a library, any program
using that lib will have that bug, no matter if statically or dynamically
linked. Just that with dynamic linking, all you need to do is recompile
the lib when a patch comes online. With static linking you'd need to
recompile the lib and all libs and programs using it. And all the programs
and libs using the libs that use the lib. And so on.

> Best regards,
>   Olaf
>

HTH,
Markus
-- 
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart terminals.