[fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.

[Bruce Tulloch]

Thanks Jonas, I think I've nailed it with your help. The linker --verbose
reports:

attempt to open
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.so
failed
attempt to open
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a
succeeded
(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a)dlopen.o
/usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function
`DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT':
dynlibs.pas:(.text.n_dynlibs_$$_loadlibrary$ansistring$$longint+0x1c):
warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking

That is, the attempt to open libdl.so failed so libdl.a was opened instead
which is the immediate reason why the link tries to link statically; the
linker did not find the .so!

The library libdl.so on the crossroot is in fact an absolute symlink:

   libdl.so -> /lib/arm-linux-gnueabihf/libdl.so.2

so arm-linux-ld ends up looking for the target of symlink
(/lib/arm-linux-gnueabihf/libdl.so.2) on the host and not on the crossroot.
Hmm.

To solve this I've replaced the symlink with a linker script of the same
name containing:

OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/arm-linux-gnueabihf/libdl.so.2
/usr/lib/arm-linux-gnueabihf/libdl.a  AS_NEEDED (
/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) )

which seems to solve the problem; with a linker script the --sysroot prefix
is applied correctly and the link completes successfully.

Thanks for all your pointers, I'm learning a lot about how ld actually
works :-)

So this raises some questions perhaps you can answer or comment on for me:

1) it seems to me that the use of absolute symlinks to resolve library
files (as opposed to relative links or linker scripts) is bad practice (at
least insofar as one may want to use them for cross compilation) but it
appears many libraries (as packaged for Debian at least) do this (use
absolute links).

Is there a reason one might need to use absolute links? If so, is there a
way (other than hacking the library files on the crossroot as I've done
here) to make cross compiling work?

On the other hand, if there is no reason to use absolute symlinks then I'm
thinking this may be worth me filing a bug report or two with Debian! It
seems one Gentoo developer think so:

   http://dev.gentoo.org/~zmedico/portage/doc/ch06s06.html

2) is there any reason linker scripts should be preferred to relative
symlinks?

3) there remains one problem; dependencies on librt.so, libgcc_s.so and
libpcre.so are not found by FPC (it does not put them in the link.res
file). However, inspecting the crossroot I can see all these libraries are
in fact absolute symlinks too so I'm guessing FPC cannot find them (when
cross compiling) for the same reason; I will replace them with linker
scripts too and try again.

Thanks for all your help and advice.

Bruce.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130524/e6627284/attachment.html>