Search code examples
dockerlinkerglibcldd

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

I have a closed source vendor library that was compiled on a glibc environment, most likely debian or ubuntu.

At work we are being hard pressed to use Alpine images, which are a muslc environment.

I have glibc on the alpine docker image. However, a lot of core musl libraries are still being looked for when running the executable.

I'm using this image as my base image as it has glibc on it. https://hub.docker.com/r/frolvlad/alpine-glibc/

I've added /usr/glibc-compat/lib/ to the LD_LIBRARY_PATH. I then run the following command.

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

It looks like libcrypt is using the glibc-compat version, but even that can't find certain symbols. I'm not an expert at this low level stuff, but is there a way to force the entire exe to use specific versions of libraries?

Solution

  • From Musl FAQ:

    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.

    In short: yes, you are going to chase ghosts by attempting to run a mixture of GLIBC and Musl-compiled DSOs. Even if you make it work today, it will likely break tomorrow when the vendor ships you a new version of GLIBC-built DSO, or when you change some of your own Musl-built DSOs.

    You should either get a source license, force the vendor to build a Musl version of the DSO, or build all of your other DSOs and the main executable against GLIBC.