[CMake] ExternalProject_Add and inheritance

[Cedric Doucet]

Hello Marc, 

thank you very much for your answer! 

I am not sure to understand how to overcome my problem with these variables. 
I can explain my problem further. 

I have a toy example of the problem which contains: 
- a call to ExternalProject_Add to install boost and yaml-ccp (the latter depends on the former) 
- a main function which loads a file with yaml-cpp (just one line of code) 

Everything compiles with GCC 5 and I obtain an executable file (called gcc_example). 
However, when I run this executable file, I get the following error message : 

./gcc_example: relocation error: ./gcc_example: symbol _ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference 

And I can overcome this problem by setting LD_LIBRARY_PATH to the right value: 

LD_LIBRARY_PATH=/home/libraries/gcc/5.2.0/lib64/ ./gcc_example 

The origin of the problem is that the definition of strings is different since GCC 5. 
Unfortunately, the default behavior is to call the C++ standard library of my Ubuntu system, and the version of this library is older than the version of GCC 5. 

I can check it with 'ldd ./gcc_example': 

linux-vdso.so.1 => (0x00007ffd02ef7000) 
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003a71400000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003d03a00000) 
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003a71000000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003d02e00000) 
/lib64/ld-linux-x86-64.so.2 (0x0000003d02a00000) 

But I don't understand why I have still this problem since I put these lines in my CMakeLists file (of course the right value of GCC_ROOT is passed to the cmake command at configuration step): 

link_directories(${GCC_ROOT}/lib64) 
target_link_libraries(gcc_example ${GCC_ROOT}/lib64/libstdc++.so) 

I can provide my simple toy example if it helps to understand. 
You just need to compile it with GCC 5 to see the problem (with older versions of GCC, everything works fine because strings are defined in the "classical" way). 

Best, 

Cédric 

----- Mail original -----

> De: "Marc CHEVRIER" <marc.chevrier at sap.com>
> À: "Cedric Doucet" <cedric.doucet at inria.fr>, cmake at cmake.org
> Envoyé: Vendredi 11 Décembre 2015 08:44:38
> Objet: Re: [CMake] ExternalProject_Add and inheritance

> With CMake, you can control compilation and link flags with the following
> environment variables:

> * CC: specify C compiler
> * CFLAGS: C compiler flags
> * CXX: specify C++ compiler
> * CXXFLAGS: C++ compiler flags
> * LDFLAGS: linker flags

> And to finish you can overload make command for generation using
> CMAKE_COMMAND option of ExternalProject_Add:
> CMAKE_CMMAND “${CMAKE_COMMAND}” -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=“…”
> “${CMAKE_COMMAND}”

> From: CMake < cmake-bounces at cmake.org > on behalf of Cedric Doucet <
> cedric.doucet at inria.fr >
> Date: Thursday 10 December 2015 at 18:21
> To: " cmake at cmake.org " < cmake at cmake.org >
> Subject: [CMake] ExternalProject_Add and inheritance

> Hello,

> I use the ExternalProject_Add command to manage third-party libraries.
> In the same time, I need to overcome some compatibility problems between GCC
> 4 and GCC 5 (strings are not defined in the same way in the STL).
> The solution I use is the one given here:
> http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5
> It allows me to force to use the libstdc++.so given by the GCC repository
> given to the cmake command.

> The problem is that trick does not work with the ExternalProject_Add command
> because configuration steps of third-party libraries are autonomous.
> Do you know how to solve the problem?

> For example, if I use the ExternalProject_Add command to manage a
> third-library whose configuration also depends on a cmake script, how could
> I tell this script to use the compilers and the libstdc++.so I provided to
> my own cmake script?

> Best,

> Cédric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151211/f22a932b/attachment-0001.html>