On Mac OS X 10.8, I have built an fpc-3.0.4 runtime-library for CPU_TARGET=x86_64 OS_TARGET=linux BINUTILSPREFIX=x86_64-linux-gnu- after building gnu binutils-2.34 for --target=x86_64-linux-gnu --host=i686-apple-darwin --build=i686-apple-darwin --prefix=/usr/local.

Now the following program crashes when compiled on OSX and executed on 64-bit debian 6.0.7.

{$linklib libgcc_s.so}
program Hello;
   uses
     cmem;
   begin
     writeln
       ( 'Hello');
   end.

but this runs fine

{$linklib libgcc.a}
{$linklib libgcc_eh.a}
{$linklib libc.a}
program Hello;
   uses
     cmem;
   begin
     writeln
       ( 'Hello');
   end.

Linking with other shared libs (maybe dependent on libgcc_so?) also causes a segmentation fault on start. All the libs are from <https://packages.debian.org/>.

My impression is that somehow linking-in the c-libs causes the entry-point of the program to be wrong. Maybe there is a linker option (I don't know of) to prevent this ?

Regards,

Adriaan van Os

Op 2020-09-01 om 20:28 schreef Adriaan van Os via fpc-pascal:

On Mac OS X 10.8, I have built an fpc-3.0.4  runtime-library for CPU_TARGET=x86_64 OS_TARGET=linux BINUTILSPREFIX=x86_64-linux-gnu- after building gnu binutils-2.34 for  --target=x86_64-linux-gnu --host=i686-apple-darwin --build=i686-apple-darwin --prefix=/usr/local.

It's been a while since I did crosscompiling regularly, but usually the key is comparing a ppas.sh/link.res  natively and cross.  FPC tries to be smart in the t_ detecting things that might not be there "cross".   Add a -k to make LD verbose and then run both, comparing output afterwards.

Also the linker might have some defaults natively that it doesn't have cross.

Adriaan van Os wrote

Linking with other shared libs (maybe dependent on libgcc_so?) also causes a segmentation fault on start. All the libs are from <https://packages.debian.org/>.

Are you using the -XR command line parameter to specify the Linux sysroot? If so, that is correct, but we still have these hardcoded Linux linker scripts in the compiler that are only used when a sysroot is specified. Maybe one of those is out-of-date...

Or, if you are not using -XR, maybe you are running into a bug that caused the addition of those hardcoded linkerscripts to the compiler in the first place (I think in some cases the linker would use a wrong linker script when cross-compiling, at least in the past).

Jonas