android-x86 builds fail on build slaves because x86 GCC is linked against a too-new glibc



Release Engineering
Platform Support
6 years ago
5 years ago


(Reporter: ted, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [android][mock])



6 years ago
I pushed a test android-x86 build to try:

and it failed because the android-x86 GCC won't run because it's linked to a glibc that's newer than what we have on the build slaves:
configure:2046: checking for /tools/android-ndk-r7b/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686
configure:2080: checking for gcc
configure:2193: checking whether the C compiler (/tools/android-ndk-r7b/toolchains/x86-4.4.3/prebuil
t/linux-x86/bin/i686-android-linux-gcc -mandroid -fno-short-enums -fno-exceptions  -mandroid -L/tool
s/android-ndk-r7b/platforms/android-9/arch-x86/usr/lib -Wl,-rpath-link=/tools/android-ndk-r7b/platfo
rms/android-9/arch-x86/usr/lib --sysroot=/tools/android-ndk-r7b/platforms/android-9/arch-x86 -llog -
Wl,--allow-shlib-undefined ) works
configure:2209: /tools/android-ndk-r7b/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linu
x-gcc -o conftest -mandroid -fno-short-enums -fno-exceptions  -isystem /tools/android-ndk-r7b/platfo
rms/android-9/arch-x86/usr/include  -mandroid -L/tools/android-ndk-r7b/platforms/android-9/arch-x86/
usr/lib -Wl,-rpath-link=/tools/android-ndk-r7b/platforms/android-9/arch-x86/usr/lib --sysroot=/tools
/android-ndk-r7b/platforms/android-9/arch-x86 -llog -Wl,--allow-shlib-undefined  conftest.c  1>&5
/tools/android-ndk-r7b/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-gcc: /lib/libc
.so.6: version `GLIBC_2.11' not found (required by /tools/android-ndk-r7b/toolchains/x86-4.4.3/prebu
configure: failed program was:

#line 2204 "configure"
#include "confdefs.h"


We'll need to figure out a way around this to get Android-x86 builds on the slaves.
(adding jhford, as he did a bunch of the work here, in case I missed anything).

From looking at, we already deployed new NDK "r7c", and new compiler/linker as part of bug#675572. (Just noticed that wiki mentions r7c, while bug mentions r7b.)

Is it possible the errors in comment#0 are actually mozconfig errors?

Comment 2

6 years ago
The exact same mozconfig works fine for me with the exact same NDK on my local Ubuntu 10.04 machine.
I would need access to one of these machines to debug this issue because it is very specific to the machine's configuration.  We only have ancient versions of glibc available on the build slaves.  We might have a newer version of glibc available in one of our custom toolchains, I wonder if we could export an LD_LIBRARY_PATH to allow the android toolchain to dynamically link against our custom gcc-4.5 toolchain's glibc.
I looked around on one of these machines and couldn't find any other glibc installations that do have the GLIBC symbol.  I tried building an alternate glibc but it didn't work.  The options I see are to upgrade the centos5 build machines to have a newer glibc or to use Mock.

It wouldn't be too hard to use the b2g build environment as a basis, with the android ndk and sdk packages in the mozilla repo (and installed) to get a basic build environment.
We should probably use mock.
John, for the ndk r7c, did you rebuild it from source? If so, any chance you linked it against the older version of ndk that is on our builders?
(In reply to Brad Lassey [:blassey] from comment #6)
> John, for the ndk r7c, did you rebuild it from source? If so, any chance you
> linked it against the older version of ndk that is on our builders?

That was a question for John Ford
We only rebuild the specific arm gcc-4.6.3 toolchain.  We just repackage the other parts, including the x86 toolchain.


6 years ago
Priority: -- → P3
Whiteboard: [android][mock]

Comment 9

5 years ago
I'm going to re-test with a Try build since we've moved our Android builds to the mock slaves.

Comment 11

5 years ago
I can't tell if this is fixed because the mock slaves only install an older NDK,and not the r7b we need to build android-x86.
We currently have green android x86 builds visible because of the work done in bug#750366.

Is there anything left to do here?

Comment 13

5 years ago
No, this was fixed by the move to mock, it was just hard to test until someone did the work to fixup the mock build configs. (Thanks Kim!)
Last Resolved: 5 years ago
Resolution: --- → FIXED


5 years ago
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.