Hi,
Cross compiling Linux-x86->eabihf of the program:
"
program rpiconsole;
uses
initc;
begin
end.
"
produces the messages:
"
Free Pascal Compiler version 3.0.1 [2015/08/14] for arm Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for ARMHF
Compiling rpiconsole.pas
Assembling rpiconsole
Linking rpiconsole
rpiconsole.pas(6) Warning: "crti.o" not found, this will probably cause a linking failure
rpiconsole.pas(6) Warning: "crtbegin.o" not found, this will probably cause a linking failure
rpiconsole.pas(6) Warning: "crtend.o" not found, this will probably cause a linking failure
rpiconsole.pas(6) Warning: "crtn.o" not found, this will probably cause a linking failure

/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/bin/ld: warning: link.res contains output sections; did you forget -T? /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
rpiconsole.pas(6) Error: Error while linking
rpiconsole.pas(6) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

"
The --verbose ld output is attached.
"
program rpiconsole;
uses
initc,xlib;
begin
end.
"
Compiles OK.
Any help appreciated.

Thanks, Martin

Martin Schreiber wrote on Fri, 21 Aug 2015:

To be able to cross-compile a program that depends on a library for any Unix platform, you need to have a sysroot available with all of those libraries and their own requirements (such as crti.o and crtn.o for glibc, and crtbegin.o and crtend.o for gcc-compiled code). That is unrelated to FPC and inherent to the way linking works on (most) Unix platforms. If you want to cross-compile using gcc or clang, you also need to have the target platform's sysroot available.

It's also unrelated to ARM. The reason it works transparently on many Unix systems for cross-compiling between x86_64 and i386, is that these systems include both a sysroot for x86_64 and for i386.

The easiest is probably to copy the entire /usr hierarchy of the Raspberry Pi to your own machine, and then pass the parent directory in which you copied that "/usr" using FPC's -XR parameter.

As mentioned in the "Issue with linking" thread, you will have to separately tell FPC where to find crtbegin.o and crtend.o, as their location depends on the GCC version used. Since the sysroot path (-XR parameter) should be prepended to any search paths specified after the -XR parameter, make sure this path is relative to the sysroot. Use FPC's -va parameter to see which search paths get added exactly in case of problems (and possibly use -Cn and inspect the generated ppas.sh and link.res).

Jonas

To allow for this, after some frustration with lesser installations, I once installed the complete code sourcery cross development suite (including Eclipse). After having done this, cross linking fpc projects was no problem any more (including building fpc itself to be run on the ARM Target).

But I don't think I'd like to recommend that method ;-) .

-Michael

On Friday 21 August 2015 11:55:49 Jonas Maebe wrote: [...]

Thanks.
The missing "_fini" and "_init" symbols from rtl/linux/arm/cprt0.as which cause the linking error are defined in one of the crt*.o files? The linker does not try to load crt*.o files:
"
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/bin/ld: warning: link.res contains output sections; did you forget -T? attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o attempt to open rpiconsole.o succeeded
rpiconsole.o
attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/system.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/system.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/lineinfo.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/lineinfo.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/exeinfo.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/exeinfo.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/strings.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/strings.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/objpas.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/objpas.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/initc.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/initc.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/ctypes.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/ctypes.o attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/unixtype.o succeeded
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/unixtype.o attempt to open ./libc.so failed
attempt to open ./libc.a failed
attempt to open /usr/local/arm-linux-gnueabihf/lib/libc.so failed attempt to open /usr/local/arm-linux-gnueabihf/lib/libc.a failed attempt to
open /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib//libc.so succeeded
-lc (/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib//libc.so) ld-linux-armhf.so.3 needed
by /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib//libc.so found ld-linux-armhf.so.3
at /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib//ld-linux-armhf.so.3 /home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/home/mse/packs/standard/svn/fp/arm/install_3_0//eabihf/lib/fpc/3.0.1/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
"
Interesting is that adding "xlib" to uses is enough to build working eabihf applications by cross compiling to Raspberry Py.

Martin

Martin Schreiber wrote

The missing "_fini" and "_init" symbols from rtl/linux/arm/cprt0.as which cause the linking error are defined in one of the crt*.o files?

Yes.

The linker does not try to load crt*.o files:

That's because the compiler warned that it could not find those files, so it didn't tell the linker to link against them either. You need the armhf sysroot for that and tell the compiler where to find it. And in addition to /usr, it's best to copy also /lib

Interesting is that adding "xlib" to uses is enough to build working eabihf applications by cross compiling to Raspberry Py.

I don't know why that would be the case.

Jonas

I got linking working without xlib in uses by copying the necessary *.o's, but now the application crashes when remote gdb tries to set a breakpoint...

I can cross compile and remote debug MSEgui applications with the mentioned setup without problems. Console applications work too if xlib is in uses. A miracle! :-)

Martin

Does it work if you don't use gdb?

Maybe the xlib unit links against a library that defines those symbols as weak symbols. This would mean that if no other code defines those symbols, the versions from that library will be used, and otherwise the versions from the other code (and you won't get duplicate symbol errors due to the weak nature).

Jonas

The "Hello World" program works but hangs after exit of main program.

Martin

Are their multiple copies of those .o files on the target system, and did you perhaps copy a wrong one? Does it work if you compile natively on the system?

Jonas

Jonas Maebe wrote

Are their multiple copies of those .o files on the target system,

No.

and did you perhaps copy a wrong one?

I don't think so.

Does it work if you compile natively on the system?

Yes.

Martin

Does it have the same version of binutils as you use to cross-compile?

Jonas

Jonas Maebe wrote

Does it have the same version of binutils as you use to cross-compile?

No.
Linux X86 cross: 2.25.51
Linux arm eabihf Raspberry Pi: 2.24.51

Martin

Looks the same with

Linux X86 cross: 2.24.0.20141017
from binutils-2_24-branch.

Martin

Martin Schreiber wrote

Looks the same with Linux X86 cross: 2.24.0.20141017 from binutils-2_24-branch.

Try
* generating linker maps (ppcarm -Xm) for both binaries and comparing them
* running "readelf -aW" on both binaries and compare the output
* runrunning "objdump -DR" on both binaries and compare the output

Jonas

Got it working! The (hopfully) last problem was a transmission problem PC -> Pi so I checked a wrong binary, thank you very much for your help.

Martin