[CMake] ExternalProject_Add and inheritance

[CHEVRIER, Marc]

The problem is not a CMake one but a runtime environment one.
You built an executable with a specific environment (GCC 5) but try to execute it in a different environment (default platform): When an executable is built, system libraries paths are not stored as part of the executable so without specific env, wrong library is used. You can solve this problem using, as you already found, LD_LIBRARY_PATH or, may be (not tried), using various CMake related RPATH variables and properties to force storage of system library path.


From: Cedric Doucet <cedric.doucet at inria.fr<mailto:cedric.doucet at inria.fr>>
Date: Friday 11 December 2015 at 10:05
To: SAP SAP <marc.chevrier at sap.com<mailto:marc.chevrier at sap.com>>
Cc: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto:cmake at cmake.org>>
Subject: Re: [CMake] ExternalProject_Add and inheritance


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





________________________________
De: "Marc CHEVRIER" <marc.chevrier at sap.com<mailto:marc.chevrier at sap.com>>
À: "Cedric Doucet" <cedric.doucet at inria.fr<mailto:cedric.doucet at inria.fr>>, cmake at cmake.org<mailto: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<mailto:cmake-bounces at cmake.org>> on behalf of Cedric Doucet <cedric.doucet at inria.fr<mailto:cedric.doucet at inria.fr>>
Date: Thursday 10 December 2015 at 18:21
To: "cmake at cmake.org<mailto:cmake at cmake.org>" <cmake at cmake.org<mailto: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/20151215/d04cecc3/attachment.html>