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

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> 
> Non-expert here.
> 
> > My project uses Synapse but features link problems and crashes when I 
> > resolve same.
> > Tracking this down:
> > 
> > Synapse uses the unit dynlibs
> > 
> > dynlibs uses the unit dl
> > 
> > dl does not have a "uses" clause, so the problem seems to be here.
> 
> In trunk it uses ctypes. I think in a lot of cases people using this 
> will also be pulling in cmem, which could fix/hide some problems.

Afaik the correct way is:

1. Avoid any explicit linking commands ($L/$linklib) to libc related files.
2. to force linking to libc, USES unit initc, it should contain a $linklib C,
   or whatever else. (linklib root on beos iirc). It also contains access to
   the threadsafe C errno.
3. Anything else is up to the compiler t_* code that creates the linker script. This
   code should recognize the need for the switch from prt0 to cprt0
  (linkliblist contains "c"), and prepare everything that is needed.

There are two problems with this:

1)
the t_* code might assume that it only need to link a certain file, and that
the linker will add other needed files.

(2) The trouble is that there are multiple such scenarios for Linux.  In
the past multiple glibc versions with different and differently named
startups, more recently uclibc, our own si_ stuff etc. It might be that the
hardcoded scenario for the platform deviates from what it really is. In the
past this was even made worse by doing runtime checks. So the availability
(or not) of a certain file might trigger a different linking scenario.

Be wary with the embedded Linuxes of filers. They often base on highly
customers (and old) MontaVista linux.