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

[Thomas Schatzl]

Hi,

On Thu, 2013-01-24 at 11:07 +0100, Michael Schnell wrote:
> On 01/23/2013 10:20 AM, Thomas Schatzl wrote:
> > program test;
> > uses cmem, dynlibs;
> > begin
> >    writeln('Hello');
> > end.
> > Compile with:
> >
> > ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
> >
> Hi Tomas.
> 
> I tested your code and compiler line on my device and it behaves as I 
> expected:
> 
> ============================================
> [/share/Public/heizarm] # ppcarm -Fl/opt/arm-linux-gnueabi/lib test.pas
> Free Pascal Compiler version 2.6.0 [2011/12/27] for arm
> Copyright (c) 1993-2011 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test.pas
> Assembling test
> Linking test
> /share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In 
> function `_haltproc_eabi':
> (.text+0x88): undefined reference to `_fini'
> /share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In 
> function `_haltproc_eabi':
> (.text+0x90): undefined reference to `_init'
> test.pas(4,18) Error: Error while linking
> test.pas(4,18) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> [/share/Public/heizarm] # cp /opt/arm-none-linux-gnueabi/lib/c
> ============================================
> 

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

Then you go on to look for crti* assembler files in the fpc svn, until I
tell you that these are provided by libc-dev package. Which was inexact,
and I got confused by your search for crti.o files (well, the answer was
exact in that I told you where you can find crti files, i.e. what you
asked for, but that was not what you wanted :]).

The "_init" and "_fini" you need are the ones from libdl.so. The linker
message doesn't help here. Crt*.o etc. are startup files for gcc
programs. Can you explain how you got to the impression that you need a
crti.o that provides _init and _fini? Just curious.

Libc-dev *also* provides a set of libc-related shared libraries that are
seemingly already in /lib. The ones provided by libc-dev export
necessary symbols for the linker during linking, the ones in /lib not.
That's why you need the -dev packages for all shared libraries you want
to link to.

Try objdump -t /lib/libdl-X.X.so and /opt/<wherever>/lib/libdl-X.X.so
and see the difference.

If you happen to finally find and specify the correct path to the
correct libdl.so it will definitely work. There is no bug in fpc.

Actually the first few answers in this thread already provide hints to
find the problem.

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

> 
> Up till now I used the gnu linker only with embedded projects in C 
> language via cross-compiling and without dynamic link libraries.
> 
> So I of course am lacking a lot of knowledge, but you might be inclined 
> to fill some gaps.
> 
> I understand that
> a) the linker does not open all files in a search directory and try to 
> find resolutions for open (non weak) externals

It tries the ones you add with {$linklib}

> b) the linker only opens the .o and .a files it is told to use (e.g. in 
> a linker script file - this is what I used in the said "C" projects)

Yes, but it's not useful here.

> c) if one of the denoted files is not found in any of the search 
> directories, the linker aborts with an error message.
> 
> Regarding my inability to link your testing program, and my other tests:
> 1) rather obviously the file crti.o is not a viable file to be used, as 
> (i) the linker will never see it unless explicitly denoted (e.g. by {$L 
> crti.o ) and this is not done in your successful test on your machine 
> and (ii) my testing programs immediately  when I include it,

see above.

> 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

> 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}. This searches for libdl.so in the a)
default paths hardcoded into fpc and b) everything specified by -Fl.

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

> 5) In dl.pp (That I understand you test program implicitly pulls), there 
> is the line {$linklib c}. I don't really understand what exactly this is 
> suppose to mean. I would _assume_ that it might be an instruction to the 
> linker to use the library file "c.a" but I believe there is no file with 
> such name. So there might be some compiler magic that constructs a 
> different instruction to the linker.

No, per shared library naming convention a "lib" prefix is added.

.a files are used to link a library statically. Not needed here, and you
don't use $linklib with them.

hth+sorry,
Thomas