How to specify the libstdc++.so.6 to use

cmakegcclibrarieslinker

I am trying to compile a program of mine, that needs C++11 features and a newer version of boost than is installed on the target machine. I therefore compiled and installed gcc 4.9 to some local directory (/secured/local) with an in-tree build of all dependencies and the binutils. I then downloaded boost 1.55 and ran ./boostrap.sh --prefix=/secured/local && ./b4 install to install boost. Both compilations worked fine and gcc -std=c++11 also works.

My program is built using cmake with the usual FindXX.cmake procedure of finding files. I am running cmake like this:

cmake ../source/ -DBOOST_ROOT=/secured/local -DCMAKE_EXE_LINKER_FLAGS='-Wl,-rpath,/secured/local/lib'

which successfully finds my new boost installation and the new version of gcc. Compilation and linking both work flawlessly. However, upon execution of my program I am getting the following errors:

$ ./surface
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./surface)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./surface)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./surface)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./surface)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /secured/local/lib/libconfig++.so.9)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /secured/local/lib/libboost_program_options.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /secured/local/lib/libboost_program_options.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /secured/local/lib/libboost_program_options.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /secured/local/lib/libboost_filesystem.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /secured/local/lib/libboost_regex.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /secured/local/lib/libboost_regex.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /secured/local/lib/libboost_regex.so.1.55.0)
./surface: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /secured/local/lib/libboost_regex.so.1.55.0)

Running objdump on boost shows

objdump -x /secured/local/lib/libboost_program_options.so.1.55.0 | grep stdc++
  NEEDED               libstdc++.so.6
  required from libstdc++.so.6:

It appears as if both the boost libs try to use the old /usr/lib64/libstdc++.so.6 instead the new one in /secured/local/lib. What did I do wrong in my procedure?

Note, that I try to avoid setting the LD_LIBRARY_PATH somewhere.

Best Answer

Installing gcc puts a libstdc++.so.6 into both $PREXIF/lib and $PREFIX/lib64. Using the latter as RPATH for boost and my program solved the issue. Using only the former results in a fall-back to the system libstdc++.so.6.

LD

You can add a file to this directory with the path to your newly installed library like so:

$ cat /etc/ld.so.conf.d/myboost.conf
/usr/local/lib/boost1.55

Then run this command:

$ ldconfig -v

This will process all the libraries and rebuild a "cache", /etc/ld.so.cache. This cache is what's used to locate libraries when they're specified like so: -lboost_thread-mgw46-mt-sd-1_54.

Example output

$ ldconfig -v
/usr/lib64/atlas:
        libclapack.so.3 -> libclapack.so.3.0
        libptcblas.so.3 -> libptcblas.so.3.0
        libf77blas.so.3 -> libf77blas.so.3.0
        libcblas.so.3 -> libcblas.so.3.0
        liblapack.so.3 -> liblapack.so.3.0
        libptf77blas.so.3 -> libptf77blas.so.3.0
        libatlas.so.3 -> libatlas.so.3.0
/usr/lib64/wxSmithContribItems:
        libwxflatnotebook.so.0 -> libwxflatnotebook.so.0.0.1
...

When adding paths to the setup, I like to confirm by going through this output to make sure things are getting picked up the way I expect them to.

LD's cache

You can always print the contents of the .cache file as well using this command:

$ ldconfig -p | head -10
2957 libs found in cache `/etc/ld.so.cache'
    lib3ds-1.so.3 (libc6,x86-64) => /usr/lib64/lib3ds-1.so.3
    libzvbi.so.0 (libc6,x86-64) => /usr/lib64/libzvbi.so.0
    libzvbi-chains.so.0 (libc6,x86-64) => /usr/lib64/libzvbi-chains.so.0
    libzrtpcpp-1.4.so.0 (libc6,x86-64) => /usr/lib64/libzrtpcpp-1.4.so.0
    libzmq.so.1 (libc6,x86-64) => /usr/lib64/libzmq.so.1
    libzmq.so (libc6,x86-64) => /usr/lib64/libzmq.so
    libzipios.so.0 (libc6,x86-64) => /usr/lib64/libzipios.so.0
    libzipios.so (libc6,x86-64) => /usr/lib64/libzipios.so
    libzip.so.1 (libc6,x86-64) => /usr/lib64/libzip.so.1

Why's my ldd output still using 1.53?

This is because your binary is using dynamic libraries. So when the binary was compiled, it was against the 1.55 versions of the libraries. However when you interrogate the binary using ldd, it's within the environment that's using the contents of the .cache file. So the library within the cache that is associated with the symbols used by this binary match those for 1.53, hence you're seeing those libraries.

Your environment knows nothing of the 1.55 libraries, only your build environment, i.e. your Makefile, is aware of this.

Dynamic libraries

Think of the functions within these as symbols. The symbols are a name, and so these names often don't change from one version of a library to another. So if you were to look at a library such as boost, you can use the tool readelf to get a list of the symbols within one of these .so files.

Example

$ readelf -Ws /usr/lib64/libboost_date_time-mt.so | head -10

Symbol table '.dynsym' contains 261 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 000000335aa096a8     0 SECTION LOCAL  DEFAULT    9 
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt8bad_castD2Ev@GLIBCXX_3.4 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNSt6locale5_ImplD1Ev@GLIBCXX_3.4 (2)
     4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _ZTINSt6locale5facetE@GLIBCXX_3.4 (2)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcslen@GLIBC_2.2.5 (3)
     6: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _ZTISt11logic_error@GLIBCXX_3.4 (2)

In the above output you can see some of the FUNC definitions, these are the names that are used to "link" a function in an executable with a function from some .so library.

I'm over simplifying this, and probably explaining things slightly off, but I'm only trying to give you a general idea of how the mechanics of how the machinery under the hood works.

References

How do I list the symbols in a .so file

Linux – ld cannot find -lgfortran

https://github.com/rs1909/knut/tree/master/knut

/usr/bin/ld: cannot find -lgfortran

/usr/bin/ld: cannot find -lquadmath

Please read knut/knut/knut.spec.cmake → Buildrequires: libgfortran-static .... i.e. libgfortran.a

Probably the same for -lquadmath : libquadmath.a

( I get no errors with the cmake configuring : The Makefile is created.)

EDIT 1, 23 June : The above appears to be a configuring example only : The Makefile was created.

Build example(s) : PCLinuxOS 2016, CentOS 7, Fedora 24 are failing with Qt5 errors.

Debian 8 Jessie : No issues, except for a cmake generated syntax error in knut/knut/build/src/config.h . $ make and # make install are OK. The gfortran, g++ are version 4.9.2 . "libgfortran-4.9-dev" provides libgfortran.a, libquadmath.a

EDIT 2, June 23 : A build with Ubuntu 16.04 ... to try out a later compiler, gcc-5.3.1 ...

cd knut/knut/build/ && CC=gcc-5 CXX=g++-5 FC=gfortran-5 cmake .. && make && sudo make install

No issues ....

EDIT 3 : Testing knut with gcc/g++/gfortran version 6.1.1 → Debian 9 Stretch.

CC=gcc-6 CXX=g++-6 FC=gfortran-6 cmake .. && make ; # make install

Is also OK.

EDIT 4 : Build requirements .. # apt-get install g++ libopenblas-dev libqt5svg5-dev

The conclusion I can have from all the above is that the used Qt5 must fit. May be there's difference in the Qt5 configuration ? patching ? ... I don't find any important difference in the Qt5 file locations.

knut