8

I have a 3rd party library compiled with gcc6 that I need to link against. So I've un-installed the standard GCC packages and installed the Software Collections devtoolset-6 package (Centos 7.4)

$ g++ -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-6/root/usr --mandir=/opt/rh/devtoolset-6/root/usr/share/man --infodir=/opt/rh/devtoolset-6/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-6.3.1-20170216/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)

However I am getting lots of link errors similar to this:

libcomsd.so: undefined reference to `operator delete[](void*, unsigned long)@CXXABI_1.3.9'

This appears to be because the devtoolset doesn't come with a version of libstd++ compiled with the new compiler, so linker is finding the standard one in /usr/lib64 which is compiled with gcc4, and thus not binary compatible with libcomsd which is compiled with gcc6.

Is there a way I can make all this work? Some package of libstd++ compiled with gcc6?

Greg
  • 393
  • 3
  • 7
  • All devtoolset compilers are built with the old libstd++. Suggest : Install `gcc63-c++-6.3.0-1.el7.x86_64.rpm` https://stackoverflow.com/questions/47175706/how-to-install-gcc-4-9-2-on-rhel-7-4/47189915#47189915 ... comes with `/usr/local/gcc63/lib64/libstdc++.so -> libstdc++.so.6.0.22` – Knud Larsen Jun 06 '18 at 12:56
  • 4
    @KnudLarsen that's inaccurate. `devtoolset-6-gcc-c++` will install `devtoolset-6-libstdc++-devel` which is the corresponding libstdc++ for GCC 6.3.1, but it only provides a static library that contains symbols not found in the older system libstdc++. The problem here is that the 3rd party library requires the new libstdc++ as a shared library, because it wasn't built with the devtoolset compiler. – Jonathan Wakely Jun 07 '18 at 12:41
  • 1
    @Greg, there's no need to uninstall the standard GCC packages to install devtoolset. – Jonathan Wakely Jun 07 '18 at 12:43
  • Thanks for your comments. For now I've obtained a version of the libstd++.so from the same source as the other library and put it in the same directory and linked with -rpath so the exe will find it. – Greg Jun 08 '18 at 04:56
  • And a thousand curses on developers who think they know better than the maintainers and decide to package their own developer tools. – Greg Jun 08 '18 at 04:58
  • As a further followup, I have .a libraries available, so I tried static linking (which is OK because the deployment environment will be a Docker container and thus no extra cost for static). This _almost_ worked, but failed because one of the third-party .a files uses Lua and has an unresolved reference to `(lua_dyn.cpp.o): undefined reference to symbol 'dlsym@@GLIBC_2.2.5'` – Greg Jun 11 '18 at 23:55

1 Answers1

0

devtoolset-9 has solved the problem of missing dynamic so library.
Absolute path is following path:

/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++.so

mariolu
  • 624
  • 8
  • 17