<div dir="ltr"><div><div><div>Thanks Jonas, I think I've nailed it with your help. The linker --verbose reports:<br><br>attempt to open /usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.so failed<br>
attempt to open /usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a succeeded<br>(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a)dlopen.o<br>/usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function `DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT':<br>
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<br>
<br>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!<br><br>The library libdl.so on the crossroot is in fact an absolute symlink:<br>
<br>   libdl.so -> /lib/arm-linux-gnueabihf/libdl.so.2<br><br>so arm-linux-ld ends up looking for the target of symlink (/lib/arm-linux-gnueabihf/libdl.so.2<span class=""></span><span class=""></span>) on the host and not on the crossroot. Hmm.<br>
<br>To solve this I've replaced the symlink with a linker script of the same name containing:<br><br>OUTPUT_FORMAT(elf32-littlearm)<br>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 ) )<br>
<br>which seems to solve the problem; with a linker script the --sysroot prefix is applied correctly and the link completes successfully.<br><br>Thanks for all your pointers, I'm learning a lot about how ld actually works :-)<br>
<br>So this raises some questions perhaps you can answer or comment on for me:<br><br>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). <br>
<br>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?<br></div><div><br>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:<br>
<br>   <a href="http://dev.gentoo.org/~zmedico/portage/doc/ch06s06.html">http://dev.gentoo.org/~zmedico/portage/doc/ch06s06.html</a><br><br>2) is there any reason linker scripts should be preferred to relative symlinks?<br>
<br></div>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.<br>
<br></div>Thanks for all your help and advice.<br><br></div>Bruce.<br><div><div><div><div><div><div><br><br></div></div></div></div></div></div></div>