977817 - Android builds fail with mysterious build error (instead of helpful warning), if you have environmental variables CC & CXX set to a native compiler ("crtbegin_dynamic.o: Relocations in generic ELF (EM: 40)")

Status: RESOLVED DUPLICATE of bug 1288313

(Firefox Build System :: General, defect)

Description

[Daniel Holbert [:dholbert]]

I just tried to build for android today, and my build errored out with:
{
 0:00.71 checking for gcc... gcc
 0:00.75 checking whether the C compiler (gcc -mandroid -fno-short-enums -fno-exceptions  -mandroid -L/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib -Wl,-rpath-link=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib --sysroot=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm -llog -Wl,--allow-shlib-undefined ) works... no
 0:00.76 configure: error: installation or configuration problem: C compiler cannot create executables.
 0:00.76 ------ config.log ------
 0:00.76 configure:2069: checking for android platform directory
 0:00.76 configure:2221: checking for host c compiler
 0:00.76 configure:2227: checking for cc
 0:00.76 configure:2262: checking for host c++ compiler
 0:00.76 configure:2268: checking for c++
 0:00.76 configure:2320: checking for ranlib
 0:00.76 configure:2355: checking for ar
 0:00.76 configure:2390: checking whether the host c compiler (cc    ) works
 0:00.76 configure:2399: cc -c   -idirafter /scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/include  conftest.c 1>&5
 0:00.76 configure:2413: checking whether the host c++ compiler (c++    ) works
 0:00.76 configure:2422: c++ -c   -idirafter /scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/include  conftest.c 1>&5
 0:00.76 configure:2442: checking for arm-linux-androideabi-gcc
 0:00.76 configure:2476: checking for gcc
 0:00.76 configure:2589: checking whether the C compiler (gcc -mandroid -fno-short-enums -fno-exceptions  -mandroid -L/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib -Wl,-rpath-link=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib --sysroot=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm -llog -Wl,--allow-shlib-undefined ) works
 0:00.76 configure:2605: gcc -o conftest -mandroid -fno-short-enums -fno-exceptions  -idirafter /scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/include  -mandroid -L/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib -Wl,-rpath-link=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib --sysroot=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm -llog -Wl,--allow-shlib-undefined  conftest.c  1>&5
 0:00.76 /usr/bin/ld.bfd.real: /scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib/../lib/crtbegin_dynamic.o: Relocations in generic ELF (EM: 40)
 0:00.76 /scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib/../lib/crtbegin_dynamic.o: error adding symbols: File in wrong format
 0:00.76 collect2: error: ld returned 1 exit status
 0:00.76 configure: failed program was:
 0:00.76
 0:00.76 #line 2600 "configure"
 0:00.76 #include "confdefs.h"
 0:00.76
 0:00.76 main(){return(0);}
 0:00.76 configure: error: installation or configuration problem: C compiler cannot create executables.
 0:00.76 *** Fix above errors and then restart with\
 0:00.76                "/usr/bin/make -f client.mk build"
 0:00.76 make[2]: *** [configure] Error 1
 0:00.76 make[1]: *** [/scratch/work/builds/fennec/fennec.14-01-09.22-26/mozilla/../obj/Makefile] Error 2
 0:00.76 make: *** [build] Error 2
}


This turned out to be because my .bash_aliases file had
 export CC=gcc
 export CXX=g++

After a lot of troubleshooting (suspecting I was missing a library or a package or something), I realized that if I unset those environmental variables, then everything worked correctly.

This appears to boil down to these lines:
{
> 150     if test -z "$CC"; then
> 151         CC="$android_toolchain"/bin/"$android_tool_prefix"-gcc
> 152     fi
> 153     if test -z "$CXX"; then
> 154         CXX="$android_toolchain"/bin/"$android_tool_prefix"-g++
> 155     fi
> 156     if test -z "$CPP"; then
> 157         CPP="$android_toolchain"/bin/"$android_tool_prefix"-cpp
> 158     fi
}
https://mxr.mozilla.org/mozilla-central/source/build/autoconf/android.m4?rev=01de43f70bed&mark=150-158#147

Those lines *used* to just directly set these variables, without checking for existing values (which would have kept me from hitting this problem), but that changed to the current form in bug 891718.

If we're going to trust the user-configured versions of these variables, I think we should at least somehow warn the user that we're using them, and that they *might* need to unset the variables if they run into build errors.

(I'll bet a lot of developers have CC=... CXX=... in their .bash_aliases or .bashrc file, and will run into this problem & get stuck, the first time they try to build for Android.)

Comment 1

[Mike Hommey [:glandium]]

What would more explicit what what you already have in your log?

checking whether the C compiler (gcc -mandroid -fno-short-enums -fno-exceptions  -mandroid -L/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib -Wl,-rpath-link=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm/usr/lib --sysroot=/scratch/work/tools/android/android-ndk-r8e/platforms/android-9/arch-arm -llog -Wl,--allow-shlib-undefined ) works... no

Comment 2

[Daniel Holbert [:dholbert]]

All that tells me is that the attempted sample-compile failed -- not why.

(and then it expands to a bunch of gunk about "crtbegin_dynamic.o: Relocations in generic ELF (EM: 40)" etc, which look like they could be library issues or who knows what. I initially thought it was that I was missing ia32-libs, but installing that didn't fix things.)

Since I haven't built for Android many times, I didn't remember that Android builds necessarily needed a special compiler (and if they needed one, I assumed that they'd be able to find it, using the --with-android-ndk etc. boilerplate in my mozconfig -- which is what used to happen, before bug 891718 landed]).

Note also that the sample .mozconfig on the wiki doesn't have any special
  CC=/path/to/special-gcc-version
  CXX=/path-to/special-g++-verison
so that also suggests that no special GCC is needed.

Maybe the right solution here is really for me to update that wiki page, with a mention of this footgun.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Mike Hommey [:glandium] from comment #1)
> What would more explicit what what you already have in your log?

(Note also that I asked about this in #mobile, with my output, and folks there didn't immediately know what was going on.  So I'm pretty sure this isn't just me being dense. :))

Anyway -- responding to your question -- ideally it'd be nice if the code referenced in comment 0 had "else" clauses, to say something like:
  WARNING: using user-provided $CC=gcc instead of arm-linux-androideabi-gcc.
  If you get build errors, you may want to unset your CC environmental variable.

But as noted in comment 2, really I'd just like for a solution to this issue to be more easily discoverable *somewhere*, and maybe the wiki is the place for that.

Comment 4

[Daniel Holbert [:dholbert]]

s/to say something like/to print out something like/

Comment 5

[Marcos A. Di Pietro]

It would be very helpful to have this information in the wiki. I spent a few hours trying to resolve this issue and researching before I came across this bug report.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks for the reminder. I added a section to the wiki:
  https://wiki.mozilla.org/Mobile/Fennec/Android#Possible_Footguns

I'll leave this open, since I still think the build system could be more helpful here.  If build folks want to resolve this as INVALID or WONTFIX, though, I'm OK with that, now that we've got the potential footgun documented somewhere at least.

Comment 7

[Nathan Froyd [:froydnj]]

Presumably for the Android case, we could at least try running:

  $CC -dM -E -x c /dev/null -o - | grep __arm__

(or whatever the correct macro here is; respectively for $CXX) and complaining if the compiler didn't define the macro we expected, which likely indicates a bug in the user's setup?

Comment 8

[Mike Hommey [:glandium]]

I actually have a patch in my queue that does that and more, waiting for me to finish writing unit tests.

Comment 9

[Mike Hommey [:glandium]]

Heh, I forgot about this bug when I finished bug 1288313. It's now essentially a dupe of that one.