[fpc-pascal] problem linking when using "cthreads" when cross-compiling for arm

[Marco van de Voort]

In our previous episode, Seth Grover said:
> 
> The way I set it up was to create a "/usr/local/bin/arm" directory,
> with symlinks in that directory like this:
> 
> $ ls -l
> total 0
> lrwxrwxrwx 1 root root 15 2010-05-24 08:53 ar -> ../arm-linux-ar
> lrwxrwxrwx 1 root root 15 2010-05-24 08:53 as -> ../arm-linux-as
> lrwxrwxrwx 1 root root 15 2010-05-24 08:53 ld -> ../arm-linux-ld
> 
> which point to the arm-linux-* binaries that were installed when I
> compiled and installed binutils for arm. I also have a
> /usr/local/lib/arm directory containing the contents of my /lib and
> /usr/lib directories which I copied over from my N800. Then, in
> fpc.cfg I have:
> 
> #ifdef cpuarm
> -Xd
> -XP/usr/local/bin/arm/
> -Fl/usr/local/lib/arm/
> #endif

(btw:
  -XP should be followed by the prefix, not the path. IOW if you do
 -XParm-linux- then you wouldn't need those symlinks.

The makefile name of this is BINUTILSPREFIX
)

> `CTHREADS_LOADPTHREADS$$BOOLEAN':
> cthreads.pp:(.text.n_cthreads_loadpthreads$$boolean+0xc): warning:
> Using 'dlopen' in statically linked applications requires at runtime
> the shared libraries from the glibc version used for linking
> /usr/local/lib/arm//libdl.a(dlopen.o): In function `dlopen':
> (.text+0xc): undefined reference to `__dlopen'
> /usr/local/lib/arm//libdl.a(dlclose.o): In function `dlclose':
> (.text+0x0): undefined reference to `__dlclose'
> /usr/local/lib/arm//libdl.a(dlsym.o): In function `dlsym':
> (.text+0xc): undefined reference to `__dlsym'
> /usr/local/lib/arm//libdl.a(dladdr.o): In function `dladdr':
> (.text+0x0): undefined reference to `__dladdr'
> runthreads.pas(28,45) Error: Error while linking
> runthreads.pas(28,45) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> Error: /usr/local/bin/ppcarm returned an error exitcode (normal if you
> did not specify a source file to be compiled)

The problem is that libdl misses functions that it should have. A list of
symbols link libdl.a (nm -a ) might help.

I suspect the target simply doesn't support dynloading of libraries.