Re: libdl bugs

Hello again,

Subject: Re: libdl bugs
Date: Sat 20.02.2010
Quoting Markus Wichmann ([email protected]):
>
>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.

I simply forgot to make the check it at the time of the implementation.
Sorry. Nobody is perfect.

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

Cover up a bug?

Sure it was an oversight to not check the ELF-header. True. That point is
taken.

But tell me if I run a dynamic linker without information where to search
the dietlibc linked libraries, how should I distiguish say libz.so that is
linked against glibc and one against dietlibc?
Both libraries have the same function entries.

If you don't provide the dynamic linker with a path to start the search,
what should the dynamic linker do?

Following the standard ELF-dynamic linker, I have implemented that the
executable compiled in path is used first. After that LD_LIBRARY_PATH.
Than I had added the search file "/etc/diet.ld.conf" to give a
distinguishing point for dynamic dietlibc libraries.

If both aren't present and you are still using the dynamic linked file I had
decided to search the content of "/etc/ld.so.conf" and that is usually
provided by glibc.

So you will naturally use the wrong libraries, if the dynamic linker is not
configured.

That I hardly see as a Bug.

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

I didn't mean that you should use libtool. I have just pointed out that
libtool usually makes compiling 'interesting'.

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

An assumption, as said I should have added the check.


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

Hamm... Ok. That is what the dynamic linker does. A program with the
DT_NEEDED for libXft.so.6 the linker will search for that library. Natrually
I assume that the Symlink "libXft.so.6" points to the correct library.

Why should the dynamic linker check the DT_SONAME?
DT_SONAME is the hint for the linker to create a DT_NEEDED with that name
in the executable/library instead of the name found in the
filesystem/symlink.

Please also consider the ELF-description for those fields.

>> Besides the installer should create all the
>> symlinks needed.
>
>Some do, some call ldconfig in hope that will do it
>

Ok never seen that. In my experience ldconfig only created the
/etc/ld.so.cache file.

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

Wonderful. Post it of send Fefe a patch for the CVS. I am sure others had
similar problems and would aprechiate it.

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

Good points for dynamic linking.
But libs (static/dynamic) using the patched lib only need to be recompiled
if the header-file changes. So only Programs need to be 'relinked'.

Neither is the Holy Grail, both link types have their strong points.
I usually use small static programs.

Best regards,
   Olaf

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