After doing some research (mostly reading
http://wiki.lazarus.freepascal.org/Setup_Cross_Compile_For_ARM) and experimenting, I am now cross compiling for ARM Linux from inside an x86 Linux VM. I followed the instructions in the aforementioned link with a few minor adjustments for my environment, and it's working quite nicely. I am able to compile FPC programs which use various RTL units and everything seems to compile fine and then rune fine when copied over to my Nokia N800.

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

so that the regular library paths aren't used (-Xd), the binutils from /usr/local/bin/arm/ are used (-XP) and the libraries in /usr/local/lib/arm/ are found (-Fl). This all seems to work fine.

FWIW, the command I used to do the crossinstall was: sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=/usr/local/bin/arm/ OPT=-dFPC_ARMEL
INSTALL_PREFIX=/usr/local

When I compile simple test programs everything is found Ok, even when using a unit like systemlog which causes libc to be linked. However, when I try to compile something that uses cthreads, I get the following errors:

$ fpc -Parm runthreads.pas
Free Pascal Compiler version 2.4.1 [2010/05/24] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling runthreads.pas
runthreads.pas(25,10) Warning: Local variable "s" does not seem to be initialized
Assembling runthreads
Linking runthreads
/usr/local/bin/arm/ld: warning: link.res contains output sections; did you forget -T?
/usr/local/lib/fpc/2.4.1/units/arm-linux/rtl/cthreads.o: In function `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)

Here's what I have pthread-related in my /usr/local/lib/arm directory:

$ ll libpthread*
-rw-r--r-- 1 root root 77k 2010-05-24 10:27 libpthread-2.5.so -rw-r--r-- 1 root root 268k 2010-05-24 10:27 libpthread.a -rw-r--r-- 1 root root 1.3k 2010-05-24 10:27 libpthread_nonshared.a -rw-r--r-- 1 root root 245 2010-05-24 10:40 libpthread.so lrwxrwxrwx 1 root root 17 2010-05-24 10:40 libpthread.so.0 -> libpthread-2.5.so

$ cat libpthread.so
/* GNU ld script
Use the shared library, but some functions are only in the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /usr/local/lib/arm/libpthread.so.0
/usr/local/lib/arm/libpthread_nonshared.a )

Does anyone have any suggestions?

Thanks,

-SG

In our previous episode, Seth Grover said:

(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
)

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.

Marco said:

Thank you, I have adjusted my setup accordingly.

Thank you for pointing me in the right direction! I have found the solution. Originally, on my device I had installed the "libc6-dev" package because it contained various object files (crti.o, for example) that FPC needed to link. After I copied the contents of /usr/lib and /lib to my cross-compile build VM, I removed the package from my device to conserve disk space.

The file "libdl.a" was included in this libc6-dev package, so I had copied it over to my build vm. However, on a whim I moved the file into the trash and tried compiling again. The compiler complained about not being able to find libdl, so I put a symlink for libdl.so.2 as libdl.so and then it compiled fine, and ran correctly as well once I copied it to the target device. So apparently having that libdl.a around was confusing things.

Thanks again for your help.

-SG