building against non-system gcc

Apr 17, 2015 at 10:41 PM
my system gcc/stdc++ is old, so I built 4.9.2 from source an it lives at /opt/gcc-4.9.2
I want to build the REST api against 4.9.2...
I've figured out most of it except for one thing, when I examine the resulting libccprest.so with ldd, it seems to be looking in /usr/lib64 for libstdc++. so it will always pick up the old one.

Q: is there a way to set rpath to my new gcc/stdc++ in the casablanca build?

thanks
Coordinator
Apr 21, 2015 at 3:13 AM
Hi mlabs,

I'm not exactly sure what the best way to do this is, but you could try adding the -stdlib=libc++ option to the CMAKE_CXX_FLAGS as indicated here.

Steve
Apr 22, 2015 at 12:06 AM
hmm still not having much luck here...

the problem seems to be that I don't know how to control the final rpath on the resulting libcpprest.so (I'm a total cmake noob, so that's not helping either).

what it is doing currently is setting rpath to the absolute path to my new boost libs, which I guess it is doing because those are calculated dependencies of libcpprest. That creates two problems, firstly, that path will be invalid when I deploy and second, it let's my old system libstdc++ so get pulled into the mix.

My plan was to use $ORIGIN/newlibs as my rpath and then have all the new boost/gcc so's in the 'newlibs' relative folder ... self contained and away from my old system libs

But I just don't know how to control rpath in a cmake build ... any tips would be greatly appreciated (the cmake manual looks pretty daunting)
Apr 22, 2015 at 7:20 PM
Edited Apr 22, 2015 at 8:18 PM
ok well I figured this out finally.

The first trick was to get cmake to stop magically generating the RPATH based on what was linking to libcpprest ...

I found that adding the following line to CMakeLists.txt:

set(CMAKE_SKIP_BUILD_RPATH TRUE)

did the trick.

Then I was able to set RPATH on the casablanca binary to whatever I liked by adding another line:

set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-rpath,/opt/foo/mynewlibs")

(in /opt/foo/mynewlibs I have my newly built boost/gcc shared libraries, kept separate from the old ones I have on my system)

and now everything looks sensible when I run 'ldd' on the binaries...

forgot to add - the script I used to build casablanca against a custom gcc/boost build is here:
export PATH=/opt/gcc-4.9.2/bin:$PATH
export BOOST_ROOT=/local/home/mlabs/boost_1_57_0
export BOOST_LIBRARYDIR=$BOOST_ROOT/stage/lib
export BOOST_INCLUDEDIR=$BOOST_ROOT/boost
export CMAKE_ROOT=/local/home/mlabs/cmake-3.2.1-Linux-x86_64

pushd casablanca.git/Release
rm -Rf build.release
mkdir build.release
pushd build.release

$CMAKE_ROOT/bin/cmake .. -DCMAKE_BUILD_TYPE=Release\
                      -DCMAKE_C_COMPILER=/opt/gcc-4.9.2/bin/gcc\
                      -DCMAKE_CXX_COMPILER=/opt/gcc-4.9.2/bin/g++\
                      -DBOOST_ROOT:PATHNAME=$BOOST_ROOT\
                      -DBoost_NO_BOOST_CMAKE=TRUE\
                      -DBoost_NO_SYSTEM_PATHS=TRUE\
                      -DBoost_LIBRARY_DIRS:FILEPATH=$BOOST_LIBRARYDIR
make
popd
popd
Coordinator
Apr 22, 2015 at 7:22 PM
Glad to hear you got everything figured out. And thanks for sharing here to help out others.

Steve
Apr 22, 2015 at 8:30 PM
no problem! - just glad I can now use your api on our dinosaur of a codebase :)