Re: Build a cross compiler for Android target (arm)

[Kai Ruottu <kai dot ruottu at wippies dot com>]

15.10.2011 12:41, BERTRAND Joel kirjoitti:

> I'm trying to build a cross compiler for Android target as I want to
> obtain a Fortran compiler.
>
> Of course, I have installed android ndk to have sysroot.
> Build process stops with :
>
> checking whether the
> /home/bertrand/android/ndk/compilers/gcc-build/./gcc/xgcc
> -B/home/bertrand/android/ndk/compilers/gcc-build/./gcc/
> -B/home/bertrand/android/ndk/compilers/arm-android-eabi/bin/
> -B/home/bertrand/android/ndk/compilers/arm-android-eabi/lib/ -isystem
> /home/bertrand/android/ndk/compilers/arm-android-eabi/include -isystem
> /home/bertrand/android/ndk/compilers/arm-android-eabi/sys-include linker
> (/home/bertrand/android/ndk/compilers/gcc-build/./gcc/collect-ld)
> supports shared libraries... yes
> checking dynamic linker characteristics... no
> checking how to hardcode library paths into programs... immediate
> checking for shl_load... configure: error: Link tests are not allowed
> after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Erreur 1

Ok, you have the GCC binaries ready (in $build/gcc) and also
libgcc (in $build/libgcc) and then your build crashes when
trying to configure libstdc++-v3 ... The C parts are OK, but
getting the C++ library fails. So what would be the sane
reaction in this situation?

For me it would be to try to compile and link a simple "Hello
World" app with the new GCC... But maybe Android is too weird
for this, no experience about whether it even supports simple
"console" apps in a terminal window, requiring some really
complex application as that "Hello World".  The very common
Windows 3.1 and its 32-bit extension "Win32s" hadn't any
console for running "text-mode Windows applications" :(

In any case installing only the GCC binaries and the libgcc
happens with :

   make install-gcc
   make install-target-libgcc

after which you can try compiling and linking that "Hello
World" and can see what errors you will get when linking...

The typical mistake is to not allow the self-made gmp, mpfr
or mpc shared libs being found by the new GCC binaries but
then the crash should happen already during the libgcc
configure - that the new 'xgcc' and 'cc1' can be started is
a sanity test there... So a "sanity test for the builder"
could be whether one is capable to try tests like :

    ./xgcc -v
    ./xgcc --help
    ./cc1 --help

in the $build/gcc directory without installing anything
there first, in order to see whether the new GCC executables
can be run in the cross host system...