我在追鬼吗? muslc 环境中 glibc exe 中的动态链接库

Am I Chasing Ghosts? dynamically linked libraries in glibc exe on muslc environment

我有一个在 glibc 环境下编译的闭源供应商库,很可能是 debian 或 ubuntu。

在工作中,我们很难使用 Alpine 图像,这是一个 muslc 环境。

我在 alpine docker 图像上安装了 glibc。但是,在 运行 执行可执行文件时,仍在寻找许多核心 musl 库。

我使用这个图像作为我的基础图像,因为它上面有 glibc。 https://hub.docker.com/r/frolvlad/alpine-glibc/

我已将 /usr/glibc-compat/lib/ 添加到 LD_LIBRARY_PATH。 然后我运行下面的命令。

ldd /app/clidriver/bin/db2cli
        /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libdb2.so.1 => /app/clidriver/lib//libdb2.so.1 (0x7f636b553000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libstdc++.so.6 => ../lib/libstdc++.so.6 (0x7f636b3ba000)
        libgcc_s.so.1 => ../lib/libgcc_s.so.1 (0x7f636b3a6000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libcrypt.so.1 => /usr/glibc-compat/lib//libcrypt.so.1 (0x7f636b36d000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f636d9de000)
        libpam.so.0 => /lib/libpam.so.0 (0x7f636b35e000)
        libxml2.so.2 => ./libxml2.so.2 (0x7f636b235000)
        libz.so.1 => /lib/libz.so.1 (0x7f636b21b000)
        liblzma.so.5 => ./liblzma.so.5 (0x7f636b1f8000)
Error relocating /app/clidriver/lib//libdb2.so.1: pthread_mutexattr_setkind_np: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: pthread_attr_setaffinity_np: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: __snprintf_chk: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: __register_atfork: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: __vsnprintf_chk: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: sysctl: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: backtrace: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: getgrent_r: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: __res_init: symbol not found
Error relocating /app/clidriver/lib//libdb2.so.1: dlvsym: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __stpncpy: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __open_nocancel: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __read_nocancel: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __snprintf: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __explicit_bzero_chk: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __libc_alloca_cutoff: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: __close_nocancel: symbol not found
Error relocating /usr/glibc-compat/lib//libcrypt.so.1: errno: symbol not found
Error relocating /app/clidriver/bin/db2cli: __printf_chk: symbol not found
Error relocating /app/clidriver/bin/db2cli: __strncat_chk: symbol not found
Error relocating /app/clidriver/bin/db2cli: __vsprintf_chk: symbol not found
Error relocating /app/clidriver/bin/db2cli: __fprintf_chk: symbol not found

看起来 libcrypt 使用的是 glibc-compat 版本,但即使那样也找不到某些符号。 我不是这种低级东西的专家,但是有没有办法强制整个 exe 使用特定版本的库?

来自 Musl 常见问题解答:

Is musl compatible with glibc?
...
  Binary compatibility is much more limited, but it will steadily increase with new
  versions of musl. At present, some glibc-linked shared libraries can be loaded with musl,
  but all but the simplest glibc-linked applications will fail if musl is dropped-in
  in place of /lib/ld-linux.so.2.

简而言之:是的,您将通过尝试 运行 GLIBC 和 Musl 编译的 DSO 的混合来追逐幽灵。即使您今天让它工作,明天当供应商向您发送新版本的 GLIBC 构建的 DSO 时,或者当您更改您自己的一些 Musl 构建的 DSO 时,它也可能会崩溃。

您应该获得源许可证,强制供应商构建 DSO 的 Musl 版本,或者针对 GLIBC 构建 所有 其他 DSO 和主要可执行文件。