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 <[email protected]<mailto:[email protected]>> Date: Friday 11 December 2015 at 10:05 To: SAP SAP <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> À: "Cedric Doucet" <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[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]<mailto:[email protected]>> on behalf of Cedric Doucet <[email protected]<mailto:[email protected]>> Date: Thursday 10 December 2015 at 18:21 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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
