Crosscompiling for armv7a: Software accesses host files

[mcc2]

Hi,

my crosscompiling toolchain/environment is working so far now...
It is possible to successfully compile applications -- I tried it with
the midnight commander and ffmpeg successfully...

However:
For example compiling the boost library (which is used a lot)
failes to compile because the compilation process "breaks out"
of the cross compilation environment and accesses (binary) files
of the host system (amd64). It failes with something like "unknown file format".

Compiling this (and other) applications/libraries natively failes due to too
less memory ...

How can I fix that?

Thank you very much in advance for any help!

Best regards,
mcc

[NeddySeagoon]

mcc2,

The cross environment gets confused when you allow .la files to be installed there as they often tell where to find other things using an absolute path.
This naturally points to your host.

Add INSTALL_MASK="*.la" to make.conf and throw away all of the .la files in your target environment on the host too.
You may want to hide them before you delete them as there are one or two that are not linker related files.

You can also try distcc and cross compiling. This will help the speed but may not help the memory issue as linking is still done on the target.
Now your cross compiler is set up and working, the hard bit is done.

I can confirm that boost does build with the ARM cross compiler as I did it yesterday.

There is a minor gotcha with cross compiling. The cross toolchain appears to use a different name for ld than the targets native toolchain, as a result, nothing built with the cross compiler runs on the target.
You need to make a new symlink in /lib so the binaries from the cross compiler can find ld.

My Pi has

[mcc2]

Hi NeddySeagoon,

thank you for your reply and help! :)

In a first step I remaind all *.la file to *.la.off and the reported problem went away!
YEAH! Boost compiles without errors.

I want to preserve the possibility to eix-sync/emerge/compile on the target. Do I need the
*.la files again? Is it possible to fix the la-problem transparently -- for example to add $ROOT
in front of the absolute paths and to set $ROOT on the target to / ?

I tried distcc beofre and was disappointed.

The ld-fix (symlinking) seems not to be necessary here: I cross-built "arss"
without that symlink and it runs fine on the target.

Is there a way to update /var/log/emerge* on the target when crosscompiling?

Thank you very much in advance for any help!

Best regards,
mcc

PS: There is a new "old" problem with *la-files.
I tried to emerge gtkdatabox, which archive comes already with a
libgladedatabox.la, which in turn accesses /usr/lib/libglade, which
fails, becaus it is amd64 and not armv7a. I cannot move the la-file
away in the middle of the linking process...
And fixing the la-file after the process fails in /var/tmp/portage/...
does also not work, because restarting the emerge process will
again unpack the archive and everything starts right from the
beginning. End of the road, here? Or is there another handy trick?