Is it possible to cross-compile a Linux/x86_64 target on a Linux/i386 host? AFAICT it should be possible and I've almost got it working (using Debian's gcc-4.4-multilib for start-up code) but the linker looks for x86_64 libraries that aren't available on a i386 system.

I'm guessing that libraries for x86_64 do not exist on most i386 distributions (since one can't run x86_64 binaries on a i386 CPU).

Normally one would cross-compile a i386 target on a x86_64 host and use the i386 compatibility libraries. I want to do it the other way around (to be able to work on an Atom netbook that does not run x86_64).

Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work?

Many thanks, Bruce.

Bruce Tulloch wrote

Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work?

-XR is for pointing the compiler/linker to the top of a complete sysroot (i.e., a hierarchy with /lib, /usr/lib etc), not to a directory with just few handpicked libraries. For the latter, use the -Fl command line switch instead, possibly combined with -Xd (to prevent the compiler from passing the default system directories as search paths to the linker).

And yes, that should indeed work fine.

Jonas

Excellent, thanks Jonas.

Closer, but not quite there yet...

To get this going I've (sshfs) mounted a 64 bit system on /mnt/engels and then attempted to cross-compile on the 32 bit system with:

fpc -MDelphi -Scgi -CX -O3 -OoUNCERTAIN -OoREGVAR \ -Tlinux -Px86_64 -Xs -XX -va -l \
-dLCL -dLCLgtk2 -XR/mnt/engels

This compiles but fails at the linker:

Searching file /mnt/engels/usr/lib64/crtn.o... found Searching file /usr/local/opt/binutils/bin/x86_64-linux-ld... found Using util /usr/local/opt/binutils/bin/x86_64-linux-ld /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 /usr/local/opt/binutils/bin/x86_64-linux-ld: cannot find /lib/libpthread.so.0
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping

The linker

/usr/local/opt/binutils/bin/x86_64-linux-ld

was created using (an appropriately modified)

fpcfixes_2.6/cross/buildcrossbinutils

i.e. built to run on i386 and target x86_64

MYINTEL=i386
TARGETS_X86_64="linux"

and the pthread library is (presumably, given the -XR option)

/mnt/engels/lib/libpthread.so

which file reports as

libpthread-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

How can I find out why x86_64-linux-ld reports it as incompatible?

Many thanks, Bruce.

Bruce,

If you are using a Debian derived distribution such as Ubuntu, you might find it easier to use debootstrap to create a 64 bit environment on your system and compile the program in that environment (see https://help.ubuntu.com/community/DebootstrapChroot for a guide). Then you can be sure that you have all the correct libraries in their standard paths, etc.

In my set up, I compile for both 64 bit and 32 bit targets on a 64 bit machine and have separate debootstrap (chroots) for each target environment rather than compile in the development environment. This ensures that the final compilation takes place in a known clean environment. I also have a chroot for a win32 cross compiler.

Once you have created the chroot for each target, all you need to do is to install the fpc debs in the appropriate environment (64 bit fpc for the 64 bit environment, 32 bit for the 32 bit environment), install any other libraries you need for the distribution repository and then compile the software in each chroot separately. The result will be executables built for each target and built in a clean environment. If you also want to generate distribution packages (debs), this is also the best way to go about it.

Regards

Tony Whyman
MWA Software

Bruce Tulloch wrote on Tue, 29 May 2012:

Closer, but not quite there yet...

[...]

fpcfixes_2.6/cross/buildcrossbinutils

Try adding --with-sysroot to the configure flags in that script.

Jonas

Hi Tony,

I use Debian as my Debian derived distro :-) I agree a minimal chroot environment for each target is a good solution but it's predicated on running a 64-bit kernel on the host (which I am trying to avoid so I can use this setup on a 32-bit capable netbook).

Looks like I might have to abandon the idea (cross compiling for a x86_64 target on a i386 host) and upgrade my mobile development platform to something with an x86_64 capable CPU in it :-/

I'll see if Jonas has any more ideas.

Cheers, Bruce.

Thanks Jonas,

I tried --with-sysroot for configure in buildcrossbinutils and it does not appear to make any difference. I still get the error "/usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0" at the link phase.

I'm thinking that ld should be looking at:

/mnt/engels/lib/libpthread.so.0

but according to the error message it's looking at:

/lib/libpthread.so.0

which read literally would explain the error. FWIW I have attached the buildcrossbinutils build log in case there's a clue in there.

Unless you have any other suggestions I might just give up and upgrade my mobile development environment to an x86_64 capable netbook and run a mixed 64/32 bit system to build 64 bit (and 32 bit) targets.

I'm guessing not many people attempt to do it the other way around these days so I might as well join the 64 bit party...

Cheers, Bruce.

That's correct. It seems that -XR isn't completely implemented on Linux in the compiler. Could you try, *instead* of using -XR, to use -k--sysroot=/full/path/to/crossroot/ ?

Jonas

I replaced the -XR option with

-k--sysroot=/mnt/engels

and that works (ie, you are correct, -XR does not appear to pass the sysroot to the linker) but there's another catch. Now I'm getting:

x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64/libdl.so when searching for -ldl

this library (on /mnt/engels) **is compatible** but it is a symlink:

/usr/lib64/libdl.so -> /lib/libdl.so.2

Given the specified --sysroot the linker should be looking at

/mnt/engels/lib/libdl.so.2

but I'm guessing it's looking at

/lib/libdl.so.2

which does not right to me. It looks like --sysroot is not analogous to chroot as far as the linker is concerned and symlinks are dereferenced literally.

For completeness I added

-XR/mnt/engels

as well, so all the (other) linker search paths are prepended with /mnt/engels. This ended up producing a slightly errnoeous message:

  x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64
  //libdl.so when searching for -ldl

Note the "//" in the reported path name before libdl.so.

This time it also reported the same error for glibc:

x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64//libglib- 2.0.so when searching for -lglib-2.0

again with the erroneous "//".

This glibc library is also a symlink to the /lib directory on engels.

I tried adding -k-rpath-link options to tell the linker to look in the relevant paths under /mnt/engels but all to no avail.

Bruce.

In follow up, I updated and rebuilt the latest binutils

http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.gz

and tried the patch associated with this bug report:

http://sourceware.org/bugzilla/show_bug.cgi?id=10340

to see if my problem was due to this bug. It does not appear to be: the link problem I've described remains true.

I'm thinking Tony Whyman's suggestion (building inside a chroot on a 64/32 bit host platform) is probably the best way forward for me now but there does look like there's a problem with FPC (i.e. handling of -XR apropos the ld) and GNU ld (i.e. the failure to prepend sysroot for symlink dereferenced library files). If you concur on the latter point, perhaps it might be worth reporting upstream to GNU?

Bruce.

Bruce Tulloch wrote on Thu, 31 May 2012:

No, on Linux it prepends the search paths with the -XR path internally in the compiler. The reason is that not all GNU binutils builds support the --sysroot parameter, and especially when -XR was implemented it wasn't very commonplace yet. That should probably be changed.

which does not right to me. It looks like --sysroot is not analogous to chroot as far as the linker is concerned and symlinks are dereferenced literally.

That's correct, --sysroot is not the same as a chroot, and I doubt it was ever meant to be. All it does is prepend the sysroot path to all searched files. It seems quite reasonable to me that in certain situations someone would want to set up their library directory with symlinks pointing to other locations on their system (e.g. for sharing files located elsewhere).

So if you want to simply copy files from another system, you'll indeed have to change some symlinks. You can try filing a bug with binutils of course, but I don't think it will be considered a bug (although you can always ask to add an option to get the behaviour you want).

Jonas

Jonas Maebe wrote

You can try filing a bug with binutils of course, but I don't think it will be considered a bug (although you can always ask to add an option to get the behaviour you want).

Thanks Jonas, I agree that this is not likely to be considered a bug by GNU but would be "nice to have" as an option for ld. I might suggest it.

Bruce.