1

I have the following program:

#include <iostream>                    

int main()                             
{                                      
    std::cerr << "hejsan" << std::endl;
} 

Compiling it with the following command:

g++ main.cpp -Wl,-rpath,/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib -std=c++11

Running ldd returns:

ldd a.out
      linux-vdso.so.1 =>  (0x00007ffe8f1eb000)
      libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000032f9e00000)
      libm.so.6 => /lib64/libm.so.6 (0x00000032f6600000)
      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000032f8a00000)
      libc.so.6 => /lib64/libc.so.6 (0x00000032f5a00000)
      /lib64/ld-linux-x86-64.so.2 (0x00000032f5600000)

As you can see it chooses libstdc++ inside /usr/lib64/libstdc++.so.6

Setting the LD_DEBUG=libs shows the following:

792127:     find library=libstdc++.so.6 [0]; searching
792127:      search path=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/tls/x86_64:/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/tls:/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/x86_64:/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib          (RPATH from file ./a.out)
792127:       trying file=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/tls/x86_64/libstdc++.so.6
792127:       trying file=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/tls/libstdc++.so.6
792127:       trying file=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/x86_64/libstdc++.so.6
792127:       trying file=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstdc++.so.6
792127:      search cache=/etc/ld.so.cache
792127:       trying file=/usr/lib64/libstdc++.so.6

This is the stdlib I want it to use: trying file=/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstdc++.so.6 but somehow it looks like the cache is being used instead. I don't have root access and can't remove anything either. How do I solve this?

This is problem because I'm using this against a more complicated code which requires GLIBCXX higher version than the stdlib inside usr/lib64 provides.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Saruman
  • 133
  • 1
  • 7
  • 1
    You also need to link with the desired library. Try something like `g++ main.cpp /app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstdc++.so ...` – Kerrek SB Dec 22 '16 at 12:12
  • Are you sure you're invoking the right compiler? What does `g++ --version` say? – Kerrek SB Dec 22 '16 at 12:13
  • And what output do you get when you try to run `ls -l /app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstdc++.so.6` – Sam Varshavchik Dec 22 '16 at 12:13
  • @KerrekSB it is the correct compiler as well, (which g++) shows /app/vbuild/RHEL6-x86_64/gcc/6.2.0/bin/g++ and the version is 6.2.0. I compile it with that compiler – Saruman Dec 22 '16 at 12:14
  • @SamVarshavchik This is the output: /app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstdc++.so.6 -> libstdc++.so.6.0.22 – Saruman Dec 22 '16 at 12:15
  • @KerrekSB I've linked it with the -L/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib -lstdc++ and still get the same problem – Saruman Dec 22 '16 at 13:00
  • Try using the `-Wl,-rpath-link` option, instead of `-Wl,-rpath`. See `ld(1)` manual page for more information. – Sam Varshavchik Dec 22 '16 at 13:30
  • @SamVarshavchik thanks mate, that did the trick – Saruman Dec 22 '16 at 14:12
  • @SamVarshavchik answered to quickly, it does link it against some other library: libstdc++.so.6 => /app/gcc/4.5.1/RHEL6/lib64/libstdc++.so.6 (0x00007fbc1b882000) but as you can see it's against 4.5.1 and not 6.2.0, Removing the gcc 4.5.1 as a module and only keeping the 6.2.0 causes it to link against usr/lib64 again. This is really weird – Saruman Dec 22 '16 at 14:16
  • So nobody knows how to link against another libstdc++? – Saruman Dec 23 '16 at 12:07
  • Do you have `/app/vbuild/RHEL6-x86_64/gcc/6.2.0/lib/libstd.so.6`? Is this a correct library for your architecture? Do you have `LD_LIBRARY_PATH` or other similar environment set? – n. m. could be an AI Apr 04 '19 at 05:31

1 Answers1

1

I think this may essentially be a duplicate of my question: Forcing or preventing use of a particular minor version of libstdc++

That question includes a way of installing programs compiled with a later version of gcc which works but may be a hack. The question seeks a better alternative and I don't have an accepted answer yet though I think I am close to one.

Its not explicitly mentioned in the question but I have newer versions of gcc installed to /opt/gcc/. I set my path to use them as follows:

PREFIX=/opt/gcc6.3.0
export C_INCLUDE_PATH=$PREFIX/include
export CPLUS_INCLUDE_PATH=$PREFIX/include
export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/lib64:$LD_LIBRARY_PATH
export PATH=$PREFIX/bin:$PATH

When configuring with cmake it can be useful to use:

CC=`which gcc` CXX=`which c++` cmake ...

to ensure cmake doesn't find the system gcc itself.

Bruce Adams
  • 4,953
  • 4
  • 48
  • 111