在 nis 和 nss 中使用未定義的引用在 arm 上編譯舊 glibc 失敗
它似乎變得有點複雜，所以首先一些背景：
我需要編譯在 arm 系統上執行的獨立程序，其
glibc版本通常在 2.13 和 2.17 之間。在嘗試執行這些程序時，我經常會收到如下錯誤：
dlopen: /lib/libc.so.6: version `GLIBC_2.26' not found (required by /tmp/_MEImvaIVL/libpython3.8.so.1.0)（在這種情況下，我使用的是帶有嵌入式 python 解釋器的程序，與 打包在一起
PyInstaller）我有一個工作流程來
python從原始碼建構在這種情況下使用的，並使用它python來建構最終包，所以我想如果我只是在正確的glibc版本下建構它，我很高興。我正在
docker使用buildah基於debian:stretch-arm32v7.經過重大的試驗和恐怖之後，
glibc最初似乎編譯得很好，但現在我被困在：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如果我進入容器並複制並粘貼上面的
gcc命令，我可以立即重現此錯誤。現在，如果我添加標誌-L/usr/lib/arm-linux-gnueabihf（其中包含主機libnss_files.so和連結器找不到的功能，並再次執行命令，我會得到同樣的錯誤，但如果我也添加-lnss_files（不出所料？）它可以工作。但這將是更多文件的情況，所以一定有更深層次的問題？令我驚訝的是
-Wl,-dynamic-linker=/opt/glibc-2.17/lib/ld-linux-armhf.so.3上面命令中的標誌。雖然這確實是最終目標 (--prefix=/opt/glibc-2.17)，但它仍然是空的，因為glibc仍在建構中。不知何故
glibc不能正確引導？有任何想法嗎？
蒂亞！
您可能需要完全引導 GCC/glibc 對 - GCC 嵌入了一些關於它建構的 C 庫的知識。
我懷疑在您的情況下，一個更簡單的解決方案是將舊圖像與舊版本的 glibc 一起使用；例如，
debian:wheezy可用於 ARMv7 並使用 glibc 2.13。