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

[Marco van de Voort]

In our previous episode, Thomas Schatzl said:
> 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.

compiler/systems/t_linux:

 if linklibc and (libctype<>uclibc) then
       begin
         { crti.o must come first }
         if librarysearchpath.FindFile('crti.o',false,s) then
           AddFileName(s);
         { then the crtbegin* }

So when the compiler _knows_ it is linking to libc, it will generate a
different link.res than without.

The compiler knows simply if the "c" name appears in the libs to link.

So there are actually four cases:

1. static FPC only application.
2. App that links to a library, but not to "c", and the library has no
reference to libc.
3. App that links to a library, but not to "c", and the library has a
reference to libc.
4. App links to library and C.

Case 1 is all FPC. 

Case 2 strictly speaking too, just passes the linked library to the linker
in link.res but both compiler and linker don't know libc is linked.  So FPC
generates a link.res for non libc linking, and ld probably doesn't link
libc.

In case 3, while FPC doesn't know about the libc linkage, it generates the
link.res like (1). ld knows that something is wrong, and _might_ add c
linking though.

Case 4 is the normal situation for libc linking.

So just to make sure that case 4 is always picked, every lib should have 
a reference to "c". When I reformed the unix lib, the idea was that simply
using "initc" should force that. (thus not having the ifdef block with
linklibs in _every_ header).