Cross compilation best practices

[LuisAnton]

Cross compiling small and self-contained programs is pretty straightforward, I have already done that. However, when projects grow and require more libraries, things get complicated. After cross-compiling two common libraries (libz, for instance) in order to have their ARM version on my x86 machine so I can link them to my bigger program, I started wondering if I was doing things properly...

Then I though that most of those libraries can be easily installed on the Sheeva with apt-get and, indeed,  I already had all the required libraries and includes in /usr/include and /user/lib. I wondered if I could simply copy those two directories on my x86 machine and use them to compile (I bet I'm missing something here, it can't be that easy)

And then I read about Scratchbox, which seems to be the Proper Way of Doing Things.

How do you cross compile? Is Scratbox the right solution?

[LuisAnton]

I was wondering...

Sheeva is powerful enough to compile small projects. The main problem is its limited read/write cycles, right? But I could simply configure the compiler to create temporary files in an external device (a hard drive, an SD card, whatever), right?

Does it make sense?

[DamonHD]

Unless you are going to be compiling large projects over and over again and you have limited free space thus probably concentrating the writes, I wouldn't worry.

But yes, probably best to at least avoid using the NAND Flash which can't be replaced.

If /tmp is mounted as tmpfs then unless the compilation makes temp files in somewhere such as /var/tmp, and you avoid compiling in an area on the NAND, you're probably OK.

(Each sold separately, batteries not included, this does not constitute financial advice, YMMV, ... B^> )

Rgds

Damon

[fragfutter]

scratchbox or pbuilder are the way.

[hansan]

I have added a howto to the wiki on how to setup scratchbox.

Greetings,

Han

[mgillespie]

scratchbox or pbuilder are the way.

Can you elaborate why?

[hansan]

For me is scratchbox2 the way because it solves a lot of hassles with keeping the arm target compatible libraries separated from  the intel 64 host libraries.

The beauty of the system is that you can work on a simulated target to test if your program is working. Within the "simulated" target environment you can use apt-get and other package manager commands to maintain the target libraries.
This is partly done by really using qemu-arm to simulate an arm architecture and partly by just mapping of the different paths between host and target root file system.

The beauty of this is that the host and target is getting transparent for the "configure" and "make" process.
After setting the system up is it possible to use "sb2 ./configure" and "sb2 make" and the make process cross compiles the program for the target; checking and linking the right libraries for the target without further compiler flags and other hassles.


BR