OSDev.org

Specifically about issues with configure/make/install using a cross-compiler for a cross-native toolchain?

Thought it'd be better if I ask before posting the question...that way if I'm in the wrong place I can get to the right one faster.

Nice Gibsonian nick!

Yes, that's perfectly on-topic. Just ask!

When you say "cross-native toolchain", it doesn't make much sense. Do you mean porting GCC to your OS? Cross and native are kinda antonyms here.

dozniak wrote:Nice Gibsonian nick!

Why thank you. Gibson is the only author I'll buy in hardcover. And trade. Yes I mean the same book

sortie wrote:When you say "cross-native toolchain", it doesn't make much sense. Do you mean porting GCC to your OS? Cross and native are kinda antonyms here.

I believe that's exactly what I mean.

Here's the basics:
I've got the standalone toolchain from the Android NDK installed (the one generated by the make-standalone-toolchain.sh script in the $NDKROOT/build/tools directory) on my CentOS build machine. If I understand correctly, it is a cross toolchain...for generating binaries that will run on Android. I've successfully built binutils using the Android NDK toolchain, to run on my Android device... and I'm trying to build gcc with the same toolchain to run on my device...but I've run into a problem with the gcc build...specifically with gmp.

Near as I can tell, the make all-gmp builds several binaries and runs them to generate some headers, like this, copy/paste: This fails because gen-fac_ui is a 32-bit ELF ARM binary...i.e. built for the host and/or target...and it won't run on my CentOS build machine.

I could use the -i or -k switch with make...but then those headers aren't generated and gcc isn't built.

So the question(s) is/are: Is there another way to generate those headers? Do I need a native (i.e. gcc for CentOS) gcc installed? Also, why is the configure and/or makefile for gmp trying to use those binaries to generate headers if I'm cross compiling?

Any and all clarification questions welcome...

EDIT: Forgot to mention build structure and sources version

I'm using gcc 4.7 source, downloaded from the Android toolchain sources using the script from the Android NDK. I used binutils 2.23 source downloaded from the same location. My build structure looks like:

gcc-bld/
gcc-bld/arm-gcc <---gcc build directory
gcc-bld/gcc-4.7 <---gcc sources

If you're aiming specifically at Android development, this may be the wrong forum for that.

dozniak wrote:If you're aiming specifically at Android development, this may be the wrong forum for that.

Maybe a generalization or restructuring of the question may help?

In general, if I have a cross toolchain installed, should I be able to configure and make for the toolchain's target without installing a native toolchain?

For example...I have a CentOS build machine on which I've installed the Android NDK toolchain. The Android toolchain runs on CentOS and produces binaries for Android. Is this enough to build gcc for android, or do I need to install gcc that runs on CentOSand produces binaries for CentOS?

And a related general question...has anyone cross-compiled GMP and if so, how did you generate those headers?

I suggest manually cross compiling (gmp, mpfr, mpc)

Owen wrote:I suggest manually cross compiling (gmp, mpfr, mpc)

Code: Select all

ANDROID=arm-android-eabi-whatever-the-android-triple-is
../(gmp|mpfr|mpc)/configure --prefix=blech --host=$ANDROID
../(binutils|gcc)/configure --prefix=blech --host=$ANDROID --target=$ANDROID

Unfortunately I tried that before posting here. I still get the same error when running make. It's still trying to run gen-fac_ui to generate mpz/fac_ui.h. Which won't work because

Hi. Be sure that your --build option is set correctly. It may somehow have become whatever-android-triplet and it accepts to use the cross-compiler (instead of the local system compiler, the build system compiler) to build the temporary programs.

sortie wrote:Hi. Be sure that your --build option is set correctly. It may somehow have become whatever-android-triplet and it accepts to use the cross-compiler (instead of the local system compiler, the build system compiler) to build the temporary programs.

The cross compiler is the only gcc installed. Are you saying that I need to install gcc for the build system (i.e. CentOS)?

If so, I'll definitely try that again. Before I posted here, I had gcc for the build system (CentOS) installed, but I ran into a different error, again with gmp; the build kept reporting that it couldn't find stdio.h, stdint.h, string.h...basically it couldn't find headers.

You actually only need to set proper --build and --target when configuring whatever you're trying to build.

Configure is particularly nasty, because if someone somewhere forgot some arcane ac_macro definition that inhibits running target tasks in cross-compile case, you'd need to patch .ac files and rerun autoconf.

So double check that
* you have specified the right cross-compiler and it is actually picked up by configure
* configure has detected --build and --target correctly
* configure has proper checks not to run target commands in case of cross-compilation

dozniak wrote:You actually only need to set proper --build and --target when configuring whatever you're trying to build.

Configure is particularly nasty, because if someone somewhere forgot some arcane ac_macro definition that inhibits running target tasks in cross-compile case, you'd need to patch .ac files and rerun autoconf.

So double check that
* you have specified the right cross-compiler and it is actually picked up by configure
* configure has detected --build and --target correctly
* configure has proper checks not to run target commands in case of cross-compilation

One and two are done and done...double-checked the Makefile and made edits where necessary.

I also made an initial pass through 22000+ lines of the configure file (gedit configure search "cross") and compared what I saw with the config.log output and it configure is detecting the cross-compile environment.

Three will be tough. I don't see where in the configure that the gen-fac_ui 32 0 >mpz/fac_ui.h is set up, and I'm not familiar with ac_ variables enough to recognize the one that inhibits target tasks. I could probably figure it out with a lot of grepping and comparison, but it would take a *lot* of grepping and a *lot* of comparison.

Will start now while waiting for a response.

Unfortunately, I don't know automake/autoconf to recommend a variable right away, digging the autohell section on StackOverflow might help.

I generally try to avoid autotools as much as possible. I managed to stick with cmake in the recent years and even the autotools code i'm building was relatively easy to port over.

dozniak wrote:Unfortunately, I don't know automake/autoconf to recommend a variable right away, digging the autohell section on StackOverflow might help.

I generally try to avoid autotools as much as possible. I managed to stick with cmake in the recent years and even the autotools code i'm building was relatively easy to port over.

That's okay.

I'm more trying to figure out why...even though the configure is detecting a cross-compile...it still generates make instructions to have gen-fac_ui build the executables.

I actually thought about switching gears to cmake, but I've put so much effort into tweaking configure and Makefiles that it doesn't seem worth it to ditch one steep learning curve in favor of another.

Off to pick through code...

EDIT: I'm new to this so I could be wrong, but is it normal practice to hard code 'none' in the CPU part of a triplet in the Makefile?

Yes, for example arm-none-eabi is valid. (Also, switching a project of size of gcc from autotools is probably over one week of work).

Quick googling shows that gen-fac_ui is part of gmp and apparently has to be built using the native toolchain (afaict, it runs on the build machine during build to generate some constants).
Make sure you have host gcc and friends available.

The gen-fac_ui is also available as source C file, so with a bit of luck you should be able to generate that one manually and replace the ARM binary with it... but I wouldn't recommend this as it masks the actual error that's happening elsewhere.