Re: libdl bugs

Olaf Dreesen schrieb:
> 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.
>

Not a problem. That's what bug reporting system are for, after all.

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

That was not the problem.

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

Use the standard path, which is what it does ATM.

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

Yes, but that was not the problem. I could configure the libdl to look
into any directory, but it would segfault if in that directory there is a
file named "libc.so" that does not contain a libc. It took me the better
part of a day to find the bug (which was made even harder because gdb
can't cope with inclusion of .c-files. It told me the segfault occured in
_dl_main.c at line 2000+whatever.)

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

Indeed it does. Did you know that GNU sed uses libtool? I'm currently
looking for alternative seds because of that. Because unless I "bootstrap"
it (dunno what that means in the context of building a simple stream
editor) it will link against libselinux, which is nonpresent in my LFS
environment.

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

And what happens then? An executable is dynamically linked against a file
which is nonexistent on the file system. As I said, DT_NEEDED may contain
stuff from DT_SONAME.

> Please also consider the ELF-description for those fields.
>

Already done. The problem is, my description says, DT_NEEDED contains the
"name of a needed library" but doesn't go into detail, whether the file
name or the soname is meant, and DT_SONAME contains the "name of the
library". So, basically, it is implemention-defined which name is taken
into account.

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

It is something apparently only GNU ldconfig does, therefore only some GNU
packages do that. But I still am sure, I read "ldconfig" in the output of
some "make install".

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

#v+
if [ -r /etc/diet.ld.conf ]
then
    libdir="$( </etc/diet.ld.conf sed '/^#/d; /^\s*$/d' | tr '\n' ':')"
fi

if [ -n "$LIBDIR" ]
then
    libdir="${libdir}${libdir:+:}$LIBDIR"
fi

if [ -z "$libdir" ]
then
    libdir="/lib:/usr/lib"
fi

if [ "$1" == "-v" ]
then
    VERBOSE="-v"
fi

oldIFS="$IFS"
IFS=:
set -- $libdir
IFS="
"

for i
do
    if [ -d "$i" ]; then
        for j in "$i"/*
        do
            if [ -f "$j" ]
            then
                soname=$(readelf -d "$j" | grep SONAME)
                if [ -n "$soname" ]
                then
                    soname=$(echo $soname | sed -e 's/.*\[//' -e 's/\].*//')
                    ln -sf $VERBOSE "$j" "$soname"
                fi
            fi
        done
    fi
done

IFS="$oldIFS"
#v-

I did not wish to enhance the script with version handling. I simply have
to hope that globbing is done in the correct order. Or the system
administrator deletes old libs immediately.

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

Oh, my bad.

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

After all, the dynamic linker is a static program. No dynamic program
would run without it.

> Best regards,
>    Olaf
>

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