[fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Thomas Schatzl]

Hi,

On Thu, 2013-01-24 at 16:13 +0100, Michael Schnell wrote:
> On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
> > Looking back, so it want's some _init and _fini...
> >

> >> 2) I suppose in your environment not crti.o, but some library (.a file
> >> or maybe some other file somehow specified) is used to resolve the _init
> >> and _finit externals.
> > libdl-<version>.so
> I see. The name in fact is "speaking" regarding it is pulled by dl.pp. 
> But the compiler magic creating "linker please look at 
> libdl-<version>.so, and do what is necessary for dynamic library 
> support" from "{$linklib c}" is far beyond my understanding.

Actually {$linklib x} searches for libx.so . But libx.so (without
version) is typically symlinked to the actual one.

> >> 3) I understand that for thut notice. I'll take another look.
> 
If you untar the fpc-<whatever> file there should be an install.sh *if*
you downloaded what I think is the tar fpc distribution.

> is, that library somehow needs to be
> >> specified, as I believe the linker will not on it's own go out and
> >> search and open files that might provide these globals.
> > Already done via {$linklib dl}.
> Ahhh. But yet I did not yet see this line. (I just found {$linklib c}). 
> Ill take another look....

The {$linklib c} is in addition to the external reference to libdl in
the function interfaces.

E.g.

function dlclose(Lib : Pointer) : Longint; cdecl; external libdl; <----

and libdl is a constant containing the 'dl' string. Again the usual
rules for name expansion apply here.

You may want to look at fpc manuals how to use external libraries and
what options there are.

> > This searches for libdl.so in the a)
> > default paths hardcoded into fpc and b) everything specified by -Fl.
> I suppose the current directory and instructions from fpc.cfg are 
> additional options.
> >> 4) Thus in your environment somehow such a library file is specified.
> >> Maybe it's done in fpc.cfg, which in my environment has not been
> >> obtained in a really "decent" way ant the syntax of which I fail to
> >> understand well enough. (The file did not come with the 2.6.0 "TAR"
> >> distribution, so it is inherited from the Debian 2.2 stuff ).
> > You can create one using the install.sh script?
> Which install.sh ? I used the one in the TAR fpc distribution and it did 
> not say it created one and I did not find it one the newly created 
> "installation dir" that I provided as the script asked me. Maybe it 
> overwrote the one in /etc without notice. I'll take another look.

If you untar the fpc-<whatever> file there should be an install.sh *if*
you downloaded what I think is the tar fpc distribution.

It would be nice, that if you have more questions about this, and you
think it's interesting, define "tar fpc distribution" after all. I.e.
give an exact location where you got it from. I seems to me I already
asked multiple times for you to tell us, and we still don't know
exactly.

> > No, per shared library naming convention a "lib" prefix is added.
> I see: {$linklib dl} is translated to libdl-<version>.so This does make 
> sense. But in the svn Trunk version of dl.pp there in fact is {$linklib 
> c} this should be translated to libc-<version>.so. I don't know how this 
> is related and maybe {$linklib dl} just is found somewhere else.

dl and its functions are special. They are typically actually
implemented in the loader (ld-linux.so) according to some websites.
ld-linux.so is more or less a fake shared library, so you cannot link to
it in the normal way.

Libdl (and always?) libc both export these symbols. But they are only
forwards to ld.so in the end I read somewhere.

E.g. do objdump -t libdl, and at least here, for e.g. dlopen it
indicates that it's a forward to the libc function.

For several reasons, compatibility is one, libdl still exists. You can
also simply use the c library in some cases it seems. Apparently the
original author of the arm/linux port found eons ago that on his
arm/linux there was no particular libdl or it did not work without the
{$linklib c}, so he added the define. Maybe it just hid a bug that was
fixed later and the linklib c forgotten. Don't read too much into some
code from r6355, especially it has a comment "arm-linux seems to require
this" going with it.

You can also see in dl.pp, that the functions dl provides is in
different libraries on different platforms.

> 
> Anyway if {$linklib dl} is in the source, a "file not found" error 
> message be issued if libdl-<version>.so is not found, but instead we 
> just see the the unresolved external messages.

FPC is not responsible for gnu ld error messages. Ask them what they
thought when implementing this. You could probably also get more
detailed information about the linking process in linux with ELF files
there too.

Thomas