`GLIBCXX_3.4.20' not found (required by kubebox)

[vlinx]

Issue with running kubebox on CentOS 7 64 bits - `GLIBCXX_3.4.20' not found (required by kubebox)

$ kubebox kubebox: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by kubebox)

$ ll /lib64/libstdc++.so.6 lrwxrwxrwx. 1 root root 19 Aug 22 17:30 /lib64/libstdc++.so.6 -> libstdc++.so.6.0.19

$ strings /lib64/libstdc++.so.6 | grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_DEBUG_MESSAGE_LENGTH

$ cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core)

[vlinx]

Is it possible to statically link libstdc++.so.6?

[astefanutti]

Thanks for the report. I've been able to reproduce. Kubebox is supposed to build Node statically, but there may be some discrepancies in the build chain. I'll dig further when I prepare the next release.

[astefanutti]

I've managed to produce some binaries that fixes the issue:

Dynamic linking using Centos 7 as host OS

$ objdump -p kubebox-dynamic-centos7

kubebox-dynamic-centos7:     file format elf64-x86-64

...

Version References:
  required from librt.so.1:
    0x09691a75 0x00 20 GLIBC_2.2.5
  required from libgcc_s.so.1:
    0x0b792654 0x00 16 GCC_3.4
  required from libm.so.6:
    0x09691a75 0x00 08 GLIBC_2.2.5
  required from libpthread.so.0:
    0x09691973 0x00 17 GLIBC_2.3.3
    0x09691972 0x00 13 GLIBC_2.3.2
    0x09691a75 0x00 06 GLIBC_2.2.5
  required from libc.so.6:
    0x09691972 0x00 18 GLIBC_2.3.2
    0x0d696913 0x00 11 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x06969194 0x00 05 GLIBC_2.14
    0x09691a75 0x00 04 GLIBC_2.2.5
  required from libstdc++.so.6:
    0x0297f864 0x00 21 GLIBCXX_3.4.14
    0x0297f868 0x00 19 GLIBCXX_3.4.18
    0x0297f861 0x00 15 GLIBCXX_3.4.11
    0x0bafd175 0x00 14 CXXABI_1.3.5
    0x056bafd3 0x00 12 CXXABI_1.3
    0x02297f89 0x00 10 GLIBCXX_3.4.9
    0x0297f865 0x00 09 GLIBCXX_3.4.15
    0x08922974 0x00 03 GLIBCXX_3.4
  required from libdl.so.2:
    0x09691a75 0x00 02 GLIBC_2.2.5

It seems that's the approach used for the official Node binary: https://github.com/nodejs/node/issues/8172#issuecomment-241829163. It's confirmed with:

$ docker run --rm node:6 objdump -p /usr/local/bin/node

/usr/local/bin/node:     file format elf64-x86-64

Program Header:
...

Version References:
  required from librt.so.1:
    0x09691a75 0x00 15 GLIBC_2.2.5
  required from libgcc_s.so.1:
    0x0b792654 0x00 12 GCC_3.4
    0x0b792650 0x00 11 GCC_3.0
  required from libm.so.6:
    0x09691a75 0x00 07 GLIBC_2.2.5
  required from libpthread.so.0:
    0x09691973 0x00 13 GLIBC_2.3.3
    0x09691972 0x00 10 GLIBC_2.3.2
    0x09691a75 0x00 06 GLIBC_2.2.5
  required from libc.so.6:
    0x09691972 0x00 14 GLIBC_2.3.2
    0x0d696914 0x00 09 GLIBC_2.4
    0x0d696913 0x00 08 GLIBC_2.3
    0x09691a75 0x00 04 GLIBC_2.2.5
  required from libstdc++.so.6:
    0x056bafd3 0x00 05 CXXABI_1.3
    0x08922974 0x00 03 GLIBCXX_3.4
  required from libdl.so.2:
    0x09691a75 0x00 02 GLIBC_2.2.5

Static linking with libgcc and libstdc++ using the --partially-static flag

$ ldd kubebox-partly-static 
    linux-vdso.so.1 =>  (0x00007ffdec9e8000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007ff9fd0c5000)
    librt.so.1 => /lib64/librt.so.1 (0x00007ff9fcebd000)
    libm.so.6 => /lib64/libm.so.6 (0x00007ff9fcbbb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff9fc99f000)
    libc.so.6 => /lib64/libc.so.6 (0x00007ff9fc5d2000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff9fd2c9000)

Fully static linking with musl using the --fully-static flag

Using the --fully-static with the standard build tool chain result in statically linked applications that require at runtime the shared libraries from the glibc version used for linking. Using musl solves that issue and I've been able to produce a fully static linked binary that works on Centos 7 (and Centos 5).

I think I'll favor the later approach and publish the binary as part of the upcoming release.

[astefanutti]

It should be fixed in version 0.3.2. Let me close this. Feel free to re-open if you face any issue.

[vlinx]

Thanks Antonin for the fantastic support. The binary is working on CentOS 7 now.