Due to a misunderstanding on how the build works, we are currently building and keeping binaries like ar, nm, objcopy etc that come from the GCC toolchain that crosstool-ng initially prepares.
These tools are built as fully static, so the even the glibc is statically compiled in. The problem is that it doesn't use the glibc version we want to target, but the one that the system where is currently built on uses.
Since we build on an Ubuntu 18.04, the included glibc version doesn't work with the old kernel that CentOS 6 has.
In general we should just switch to the LLVM counterparts, since they are all available, so ar -> llvm-ar, nm -> llvm-nm and so on.
While it's true that it's rare that the toolchain is used on CentOS 6 directly to build osquery, it's a problem when having to re-generate the configuration for the third party libraries.
A workaround can be done by creating some symlinks.
Due to a misunderstanding on how the build works, we are currently building and keeping binaries like
ar,nm,objcopyetc that come from the GCC toolchain that crosstool-ng initially prepares.These tools are built as fully static, so the even the glibc is statically compiled in. The problem is that it doesn't use the glibc version we want to target, but the one that the system where is currently built on uses. Since we build on an Ubuntu 18.04, the included glibc version doesn't work with the old kernel that CentOS 6 has.
In general we should just switch to the LLVM counterparts, since they are all available, so
ar->llvm-ar,nm->llvm-nmand so on.While it's true that it's rare that the toolchain is used on CentOS 6 directly to build osquery, it's a problem when having to re-generate the configuration for the third party libraries.
A workaround can be done by creating some symlinks.