[fpc-pascal] Linking Problems while cross compiling for arm

[Jonas Maebe]

On 07 Dec 2009, at 13:41, Hartmut Eilers wrote:

> ubuntu at kubuntu904:~/OpenLabTools/DeviceServer$
> /usr/local/bin/ppcrossarm -CfFPA  -dUSB92 -CaARMEB -CpARMV5 -darm
> -dFPC_ARMEL  -gl -Fu../webserver -Fu../PhysMach
> -Fu../divLibs/pwu-1.6.0.2-src/main/
> -FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ 
> ld-uClibc.so.0
> -Fl/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux- 
> uclibc/lib/
> -XParm-unknown-linux-uclibc- -Xd
> -Xr/usr/local/xtools/arm-unknown-linux-uclibc/
> -XR/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux- 
> uclibc/
> -k"-L/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux- 
> uclibc/lib"
> DeviceServer.pas
> Free Pascal Compiler version 2.4.0rc1 [2009/12/07] for arm
> Copyright (c) 1993-2009 by Florian Klaempfl
> Target OS: Linux for ARM
> Compiling DeviceServer.pas
> DeviceServer.pas(538,10) Warning: Function result does not seem to  
> be set
> Assembling deviceserver
> Linking DeviceServer
> /usr/local/xtools/arm-unknown-linux-uclibc/bin/arm-unknown-linux- 
> uclibc-ld:
> cannot find -ldl
> DeviceServer.pas(609,2) Error: Error while linking
> DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module,  
> stopping
> Fatal: Compilation aborted
>
> ubuntu at kubuntu904:~/OpenLabTools/DeviceServer$ ls
> /usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/ 
> lib
> ldscripts            libgomp.a         libmudflap.la
> libnsl.so.0           libssp_nonshared.la  libsupc++.a
> ld-uClibc-0.9.30.so  libgomp.la        libmudflap.so
> libpthread-0.9.30.so  libssp.so            libsupc++.la
> ld-uClibc.so.0       libgomp.so        libmudflap.so.0
> libpthread.so.0       libssp.so.0          libthread_db-0.9.30.so
> libcrypt-0.9.30.so   libgomp.so.1      libmudflap.so.0.0.0
> libresolv-0.9.30.so   libssp.so.0.0.0      libthread_db.so.1
> libcrypt.so.0        libgomp.so.1.0.0  libmudflapth.a
> libresolv.so.0        libstdc++.a          libuClibc-0.9.30.so
> libc.so.0            libgomp.spec      libmudflapth.la
> librt-0.9.30.so       libstdc++.la         libutil-0.9.30.so
> libdl-0.9.30.so      libiberty.a       libmudflapth.so
> librt.so.0            libstdc++_pic.a      libutil.so.0
> libdl.so.0           libm-0.9.30.so    libmudflapth.so.0      libssp.a
>             libstdc++.so
> libgcc_s.so          libm.so.0         libmudflapth.so.0.0.0
> libssp.la             libstdc++.so.6
> libgcc_s.so.1        libmudflap.a      libnsl-0.9.30.so
> libssp_nonshared.a    libstdc++.so.6.0.10
>
>> From my point of view the -k"-L..." is the correct path and libdl is
> located there.
>
> Can anybody enlighten me in this ?

This is not specific to ARM or Linux. When you compile on a Unix  
platform and you want to link to a library, then normally you have to  
have the "development" variant of the package to which that library  
belongs installed. This development package will then normally install  
a symlink in /lib or /usr/lib called lib<name>.so, which points to the  
latest version of that library on your system.

When you specify to the linker that you want to link against a  
library, you tell the linker -l<name>, and the linker will than look  
for lib<name>.so in all library search paths. You only have a libdl.so. 
0, so it's normal that the linker does not find it.

I don't know whether this means that you are missing some development  
package, whether this means that you should never explicitly link any  
program against libdl on uclibc systems, or something else.


Jonas