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
_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to