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

[Jonas Maebe]

On 07 Dec 2009, at 10:46, Hartmut Eilers wrote:

> I try to crosscompile one of my projects to the arm based
> USB9263 from Calao Systems
> (http://www.calao-systems.com/articles.php?lng=en&pg=5932)
>
> I get the following linking error:
>
> 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/ 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/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function  
> `_start':
> (.text+0x4c): undefined reference to `__libc_start_main'
> /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function
> `_haltproc_eabi':
> (.text+0x88): undefined reference to `_fini'
> /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function
> `_haltproc_eabi':
> (.text+0x90): undefined reference to `_init'
> DeviceServer.pas(609,2) Error: Error while linking
> DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module,  
> stopping
> Fatal: Compilation aborted

-Xr only passes -rpath-link to the linker. See "man ld" and search for  
"rpath-link" to see what this does exactly (it's a long and  
complicated explanation). As Marco already said, the problem above is  
that the compiler is not finding the uclibc files, and hence assumes  
glibc. Add -XR/usr/local/xtools/arm-unknown-linux-uclibc/ to also make  
the compiler look in the right place.

However, note that uclibc support has not been maintained since a long  
time, is completely untested with ARM/EABI by FPC developers, and is  
known not to work without manually patching the the RTL startup code  
in case you link against C libraries (see the thread "change default  
start function in cprt0.o" at http://lists.freepascal.org/lists/fpc-devel/2009-December/thread.html) 
. Since I didn't see a follow-up yet to the last messages in that  
thread, I don't know whether it works afterwards.

> I have built my own crosscompiler with fpc 2.2.2.

Note that building the next release or current development trunk is  
always only supported when starting the compilation using the previous  
release (in this case: use FPC 2.2.4 to compiler 2.4.0rc1). Using a  
previous release might also work, but is untested and unsupported  
(although in case that is unlikely to have anything to do with the  
issues you are encountering).

> Especially the steps building the crosscompiler.

Those look fine.

> I also tried to use the -k ... with sys-root but the the linker
> complains that he couldn't find the dl lib. I guess I have something
> wrong with the pathes of the -F* parameters.
>
> 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

Even if your compilation work, your resulting binary would not run,  
because this would write "/usr/xtools/arm-unknown-linux-uclibc/arm- 
unknown-linux-uclibc/lib/ld-uClibc.so.0" as dynamic linker in your  
binary. Since that file is unlikely to exist on your device, it  
wouldn't work (although as far as I can tell from cursory inspection,  
the compiler completely ignores the -FL setting for Linux, which does  
not seem to be documented anywhere nor even mentioned in a comment).

> -Fl/lib/

Why do you pass /lib as a library search path when cross-compiling?

> -XParm-unknown-linux-uclibc- -Xd
> -Xr/usr/local/xtools/arm-unknown-linux-uclibc/ -Fi
> /usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/ 
> include/c++/4.3.2/
> -k"--sysroot=/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown- 
> linux-uclibc/include/c++/4.3.2/sys-root/"
> DeviceServer.pas
> Warning: Only one source file supported, changing source file to
> compile from "/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown- 
> linux-uclibc/include/c++/4.3.2/"
> into "DeviceServer.pas"

Note this warning. It's due to the space between -Fi and /usr/local/ 
xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/include/c++/ 
4.3.2/. On the other hand, FPC cannot read C(++) include files, so for  
the actual compilation it does not matter.

> 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

I guess this is due to the missing -XR parameter.


Jonas