compiling old glibc on arm fails with undefined references in nis and nss

Question

It seems to have become a bit complex, so first some background:

I need to compile self-contained programs that run on arm systems with glibc versions typically between 2.13 and 2.17.

When trying to run these programs, I often get an error like this:

dlopen: /lib/libc.so.6: version `GLIBC_2.26' not found (required by /tmp/_MEImvaIVL/libpython3.8.so.1.0)

(In this case I'm using a program with embedded python interpreter, packaged with PyInstaller)

I have a working workflow to build the python used in that case from source, and use that python to build the final package, so I figured if I just build it under the right glibc version I'm good to go.

I'm using build containers (first docker, now buildah (since it gives me much more flexibility to interact with my build containers)), based on debian:stretch-arm32v7.

After significant trial & horror, glibc seems to compile quite well initially, but now I'm stuck at:

gcc -no-pie -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/opt/glibc-2.17/lib/ld-linux-armhf.so.3  -B/buildroot/build/csu/  -Wl,--version-script=/buildroot/build/libnss_db.map -Wl,-soname=libnss_db.so.2 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both  -L/buildroot/build -L/buildroot/build/math -L/buildroot/build/elf -L/buildroot/build/dlfcn -L/buildroot/build/nss -L/buildroot/build/nis -L/buildroot/build/rt -L/buildroot/build/resolv -L/buildroot/build/crypt -L/buildroot/build/nptl -Wl,-rpath-link=/buildroot/build:/buildroot/build/math:/buildroot/build/elf:/buildroot/build/dlfcn:/buildroot/build/nss:/buildroot/build/nis:/buildroot/build/rt:/buildroot/build/resolv:/buildroot/build/crypt:/buildroot/build/nptl -o /buildroot/build/nss/libnss_db.so -T /buildroot/build/shlib.lds /buildroot/build/csu/abi-note.o -Wl,--whole-archive /buildroot/build/nss/libnss_db_pic.a -Wl,--no-whole-archive /buildroot/build/elf/interp.os /buildroot/build/linkobj/libc.so /buildroot/build/libc_nonshared.a /buildroot/build/nss/libnss_files.so
/buildroot/build/nss/libnss_db_pic.a(db-proto.os): In function `_nss_db_getprotoent_r':
db-proto.c:(.text+0x15c): undefined reference to `_nss_files_parse_protoent'
/buildroot/build/nss/libnss_db_pic.a(db-proto.os): In function `_nss_db_getprotobyname_r':
db-proto.c:(.text+0x268): undefined reference to `_nss_files_parse_protoent'

... (more failing functions) ...

collect2: error: ld returned 1 exit status
../Makerules:446: recipe for target '/buildroot/build/nss/libnss_db.so' failed
make[2]: *** [/buildroot/build/nss/libnss_db.so] Error 1

If I enter the container and copy&paste above gcc command, I can immediately reproduce this error. Now if I add the flags -L/usr/lib/arm-linux-gnueabihf (which contains the host's libnss_files.so and the functions the linker can't find, and execute the command again, I get the same error, but if I also add -lnss_files (unsurprisingly?) it works. But this will be the case for many more files, so there must be a deeper lying problem?

What surprises me is the flag -Wl,-dynamic-linker=/opt/glibc-2.17/lib/ld-linux-armhf.so.3 in above command. While that indeed is the final target (--prefix=/opt/glibc-2.17), it is still empty since glibc is still being built.

Is somehow glibc not bootstrapping correctly?

Any ideas?

TIA!

Answer 1

You probably need to bootstrap the GCC/glibc pair completely — GCC embeds some knowledge of the C library it was built with.

I suspect a simpler solution in your case is to use older images with older versions of glibc; for example, debian:wheezy is available for ARMv7 and uses glibc 2.13.