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" <[email protected]>
> À: "Cedric Doucet" <[email protected]>, [email protected]
> 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 < [email protected] > on behalf of Cedric Doucet <
> [email protected] >
> Date: Thursday 10 December 2015 at 18:21
> To: " [email protected] " < [email protected] >
> 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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
