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

[Michael Schnell]

On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
> Looking back, so it want's some _init and _fini...
>
> In your mail titled "[fpc-devel] Install fpc and Friends on a non-Debian
> ARM-Linux Device" you state:
>
> "I found, that _fini and _init *should* be provided by crti.o which is
> not included in the packages I installed. And I don't know how to find
> out which package might provide it."
In the Internet, I found the hint to use crti.o. But now I don't believe 
that this is a valid advice.
> The "_init" and "_fini" you need are the ones from libdl.so.
I am very inclined to believe that you are right, but seemingly in my 
project libdl.so is not linked in (I hope to find out, how an .so is 
"linked" at compile time, how it is made known to the linker in your 
environment and why it does not work in my environment, so I'm eagerly 
reading on....)
> Can you explain how you got to the impression that you need a
> crti.o that provides _init and _fini? Just curious.
Just using Google I found this advice in some forums.
> If you happen to finally find and specify the correct path to the
> correct libdl.so it will definitely work.
I'll try this. But I still fail to understand how the linker is supposed 
to know that it should look into this file.
> There is no bug in fpc.
I hoped this and that is why I did not file a Mantis entry right away.
>> Obviously something in my installation is different.
>>
>> /opt/arm-linux-gnueabi/lib is exactly the location where I copied crti.o
>> from.
>>
>> I still don't see the difference between copying the file to the current
>> dir and using -Fl to add that dir to the library search path.
> Because it's the wrong _init and _fini.
Yep. In other words: crti.o is the wrong file. (even though (IIRC) it is 
in the dir you told me to provide in "-Fl"

> It tries the ones you add with {$linklib}
That is what I understand, but the line I saw in the unit in question 
(dl.pp) confusingly is {$linklib c} and there is no c.whatever file that 
is supposed to be linked in..
>> 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.
>> 3) I understand that for this, 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....
> 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.
>
> 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.

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.
> .a files are used to link a library statically. Not needed here, and you
> don't use $linklib with them.
I understand (just curious: is there another {$??? } instruction for 
static libraries ?
> hth+sorry,
I am very happy with all the valuable information I got.

-Michael