1

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!

2
  • Are you doing a full gcc/glibc bootstrap, or just glibc? – Stephen Kitt Jun 25 '20 at 17:51
  • @StephenKitt for now I focused on glibc, but it it turns out I run into problems related to gcc (I'm now just using the one from debiab:stretch-arm32v7), I might need to include it as well... – ppenguin Jun 26 '20 at 11:53
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.

2
  • Thanks a lot, I'll try that first and report back... – ppenguin Jun 26 '20 at 12:07
  • Great, it worked! It was not completely trivial, since wheezy is so old it is hidden in the debian archives, and a few deps for python (notably ` openssl) where difficult, mainly because python` tells you version 1.0.2 is sufficient, but it is not. So needed to install that from source. But Now I have nice build containers based on glibc-2.13-armhf – ppenguin Jun 27 '20 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.