Wannabe Cross-Compiler(Er)

[relliker]

Hi folks,

I'm not a developer and never did any cross-compilations before but I'm quite an old hand at native compiling from source (x86).
I would like to do some cross-compiles for the Pandora and have two questions/requirements.

1) Is cross-compiling for arm just the same matter of knowing how to ./configure --stuff and solve dependencies like when compiling natively or does it require porting/adapting the code to run on the Pandora-specific hardware first (which would end this topic immediately for me) ?

2) If it's a matter of configure/make, can someone point me to any noob tutorial on setting up a cross-compile platform for the Pandy starting with an x86 base?

Thanks in advance for any/all replies.

 

[viridior]

For the most part, cross compiling should be fairly straight forward. Have a cross toolchain installed and set your CHOST and CBUILD variables accordingly.

That said, there are a many programs that need some patching to compile correctly. KDE (in general) is notorious for not cross-compiling well. GNOME is better, but it has some issues too. Xorg has a few problem children. It really is on a case-by-case basis on how well that package follows gcc standards, how asm dependent it is, and whether it's configuration files took into account that it may be cross-compiled (where is spend 90% of my time).

If you plan on cross-compiling for AIOS/Angstrom you probably will save a bit of time using the OE framework. There are others out there, scratchbox comes to mind. I also have one that I developed for Gentoo that builds on the crossdev env that pops out tarballs that you could also use if you wanted to do something similar to LFS.

 

[skeezix]

the only real trick is that most configure-scripts assume they cna check current machine for libs, and assume they're present for build time and/or run-time; in effect the configure-script needs to be aware of what native-li bs it needs (for test-compile jobs), what target-arch libs it needs (for linking and dyn-linking references) .. but for unbehaved scripts you can often just do a ./configure, then hack the resulting Makefile and be good to go.

But yeah, generally you've just got an alternate dir-tree with gcc-and-friends, libs, etc, so just need your build process referring to those, instead of the native set.

Consider: some emulators build intermediate jobs, which in turn spit out C or ASM used for later builds. ie: they might emit a program which in turn runs and spits out a CPU emulator core, which you then build. So the configure job needs to be smart enough to realize that it needs to build the first stepnative, and then have that guy emitting aa tool built using target-arch gcc instead.

jeff

 

[relliker]

Thanks for the info folks! Much appreciated. My old PIII's going to get re-purposed for Pandora code-pushing quite soon! I was delaying the installs until I had some more facts to add to my mental notes

Edit: I'm not worried about humongous projects like KDE not compiling without patching. I think I will mostly be compiling small utils like socat and stuff to play with some audio generation/streaming.