I'm using CLion IDE, Cmake with GCC compiler and I'm trying to run binary with address sanitizer. I followed this: What's the proper way to enable AddressSanitizer in CMake that works in Xcode and added
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")
to CMakeLists.txt file and then got an error when running the binary in CLion using the run button:
==22084==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
When I run the binary via terminal, it works as it should be. It doesn't work in CLion's run window. https://imgur.com/a/MXOM7BJ
Edit: The solution was adding LD_PRELOAD=libasan.so.5 to environment variables of CLion.
My CMakeLists.txt:
cmake_minimum_required(VERSION 3.17)
project(Playground)
set(CMAKE_CXX_STANDARD 14)
add_executable(Playground main.cpp)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -g")
What's happening?
Adding these lines from the stackoverflow thread to CMakeLists.txt file didnt work too.
set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set(CMAKE_EXE_LINKER_FLAGS_INIT "-fsanitize=address -fno-omit-frame-pointer")
and this line from this guide https://www.jetbrains.com/help/clion/google-sanitizers.html#LSanChapter also didnt work
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer -O1")
Then I tried adding LD_TRACE_LOADED_OBJECTS=1 to CLion environment variables and nothing changed.
My ldd ./file command output of the binary:
linux-vdso.so.1 (0x00007ffd82d96000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f7d532e1000)
libasan.so.5 => /lib/x86_64-linux-gnu/libasan.so.5 (0x00007f7d528af000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7d526bd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7d526b7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7d52694000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7d52689000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7d52538000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7d5251d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7d5350c000)
First remove all of the set commands you added, and then add these commands before the compile:
add_compile_options(-fsanitize=address)
add_link_options(-fsanitize=address)
The problem is caused by the LD_PRELOAD=libgtk3-nocsd.so.0 setting somewhere in your environment. Overwrite it or unset the variable in your CLion run configuration.
Related
I am trying to use a few imported shared libraries in a project which is to be tested through GTest. If I create test executables manually (e.g. without GTest), everything works fine. However, when enabling executables that rely on GTest, the build crashes with the following error:
<path to build dir>/test_gtest: error while loading shared libraries: ./libDependencyL2.so: >cannot open shared object file: No such file or directory
CMake Error at /usr/share/cmake-3.24/Modules/GoogleTestAddTests.cmake:112 (message):
Error running test executable.
Path: '<path to build dir>/test_gtest/test_gtest'
Result: 127
Output:
Call Stack (most recent call first):
/usr/share/cmake-3.24/Modules/GoogleTestAddTests.cmake:225 (gtest_discover_tests_impl)
I am using CMake as the build system. Compilation and running take place on a x86 Ubuntu 20.04.
Project structure
My directory structure is:
test_project/
CMakeLists.txt
src/
test_handcrafted/
CMakeLists.txt
test_handcrafted.cpp
test_gtest/
CMakeLists.txt
test_gtest.cpp
test_utils
CMakeLists.txt
test_utils.cpp
test_utils.hpp
lib/
libTarget.so
Target.hpp
libDependencyLevel1.so
DependencyLevel1.hpp
libDependencyLevel2.so
DependencyLevel2.hpp
build/
libTarget.so contains the functionalities to be verified. libDependencyLevel1.so contains utils for visualizing test outputs and it depends on libDependencyLevel2.so. test_utils contains all functions and classes that are actually called by the tests.
For instance, the command $ldd libDependencyLevel1.so returns:
linux-vdso.so.1 (0x00007fff17bb6000)
libDependencyLevel2.so => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe5f3357000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe5f333c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe5f314a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe5f2ffb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe5f358d000)
Build system
test_project/CMakeLists.txt
project(MY_TEST)
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(ExternalProject)
add_library(libTarget SHARED IMPORTED)
set_target_properties(libTarget PROPERTIES
IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/lib/libTarget.so"
)
add_library(libDependencyLevel2 SHARED IMPORTED)
set_target_properties(libDependencyLevel2 PROPERTIES
IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/lib/libDependencyLevel2.so"
)
add_library(libDependencyLevel1 SHARED IMPORTED)
set_target_properties(libDependencyLevel2 PROPERTIES
IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/lib/libDependencyLevel2.so"
)
add_dependencies(libDependencyLevel1 libDependencyLevel2)
include(FetchContent)
FetchContent_Declare(
googletest
URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip
)
set(MY_LIBRARIES_HEADERS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/lib)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/src/test_utils)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/src/test_handcrafted)
# add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/src/test_gtest) # UNCOMMENTING THIS LINE CAUSES BUILD ERROR
src/test_utils/CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_library(test_utils test_utils.cpp)
target_include_directories(test_utils PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}
MY_LIBRARIES_HEADERS_DIR
)
target_link_libraries(test_utils PUBLIC libTarget libDependencyLevel1 libDependencyLevel2)
src/test_handcrafted/CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(test_handcrafted test_handcrafted.cpp)
target_link_libraries(test_handcrafted PRIVATE libTarget test_utils)
src/test_gtest/CMakeLists.txt
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(test_gtest test_gtest.cpp)
target_link_libraries(test_gtest PRIVATE libTarget test_utils GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(test_gtest)
Finally, when building test_handcrafted.cpp we can also check its dependencies ldd test_handcrafted:
linux-vdso.so.1 (0x00007ffdaa561000)
libTarget.so => <path to repo dir>/lib/libTarget.so (0x00007ff7ab7ab000)
../lib/libDependencyLevel1.so (0x00007ff7ab76d000)
../lib/libDependencyLevel2.so (0x00007ff7ab612000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff7ab3e5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff7ab294000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff7ab279000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff7ab087000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff7ab064000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff7ab05e000)
./libDependencyLevel2.so => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff7ab040000)
libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007ff7aafbb000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff7ac01b000)
Unsuccessful solution attempts
Here is a list of things I have tried without success to solve the issue:
target_link_libraries on test_project/CMakeLists.txt
target_link_libraries(libDependencyLevel1 PUBLIC libDependencyLevel2) # INTERFACE and PRIVATE specifiers were also evaluated
link_directories on test_project/CMakeLists.txt
link_directories(${CMAKE_CURRENT_SOURCE_DIR}/lib)
Reasoning and questions
According to the error message shown in the beginning of this post, the build system is not finding the shared libraries needed when GTest is used. But why is this happening? And why not using GTest solves the linking error, even if the IMPORTED SHARED libraries are imported in the same way for building both executables?
Finally, what can I do to solve the building issue when using GTest?
I have application built in Ubuntu 14.04 / GCC 4.8 / CMake 2.8 with -static-libgcc and -static-libstdc++. ldd command shows:
linux-vdso.so.1 => (0x00007ffc16195000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcb18256000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcb17f50000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb17b8a000)
/lib64/ld-linux-x86-64.so.2 (0x000055fc367e1000)
When I add -static to CMAKE_EXE_LINKER_FLAGS - I got different output from ldd:
linux-vdso.so.1 => (0x00007ffd48349000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe8d0335000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe8d0031000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe8cfd2a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8cf965000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055d61ec7d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe8cf74f000)
I supposed -static flag will result in static linked application. It did not happen.
May anyone explain me why ?
I have makefile generated by Qt Creator - with -static switch build results in fully static application.
-static is different from -static-libgcc and -static-libstdc++ specifically in that -static does not assume static linking of standard libraries. Those two flags control this behavior.
To link statically with standard libraries, add those two flags to CMake CMAKE_EXE_LINKER_FLAGS variable.
It is from resulting CMakeLists.txt. I use -DSTATIC_LINKING=True when running CMake.
IF(STATIC_LINKING)
SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
ENDIF(STATIC_LINKING)
# libpcap library
find_library(pcap libpcap.a)
# opencore-amr libraries
find_library(opencore-amrnb libopencore-amrnb.a)
find_library(opencore-amrwb libopencore-amrwb.a)
# c++ netlib
find_library(cppnetlib-server-parsers libcppnetlib-server-parsers.a)
find_library(cppnetlib-uri libcppnetlib-uri.a)
find_library(cppnetlib-client-connections libcppnetlib-client-connections.a)
# pthread
find_library(pthread libpthread.a)
# boost libraries
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
# set -static, when STATIC_LINKING is TRUE and set LINK_SEARCH_END_STATIC
# to remove the additional -bdynamic from the linker line.
IF(STATIC_LINKING)
SET(CMAKE_EXE_LINKER_FLAGS "-static -static-libgcc -static-libstdc++"
SET_TARGET_PROPERTIES(pvqa-server PROPERTIES LINK_SEARCH_END_STATIC 1)
ENDIF(STATIC_LINKING)
Point me in the right direction if this has been asked before. I have lib1 and mod2, which must be linked together. This project is spread to a couple of folders and a couple of CMakeLists.txt files. The cmake commands that I am using are as such:
cmake file 1 (base dir):
# Set C/C++ compile and linking flags
set(GCC_COVERAGE_COMPILE_FLAGS "-fpic -Wno-as-needed")
set(GXX_COVERAGE_COMPILE_FLAGS "-std=c++11")
set(GXX_COVERAGE_LINK_FLAGS "-Wl,--no-undefined -Wno-as-needed")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS} ${GXX_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER__FLAGS} ${GCC_COVERAGE_LINK_FLAGS}")
cmake file 2 (lib1 dir):
pybind11_add_module(elka_comm__common
SHARED
pyelka_common.cpp
elka.cpp
elka_comm.cpp
)
set_target_properties(elka_comm__common PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${ELKA_BINARY_DIR}/python
)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS} ${GXX_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER__FLAGS} ${GCC_COVERAGE_LINK_FLAGS}")
add_dependencies(elka_comm__common msg_gen)
cmake file 3 (mod2 dir):
#FIXME ldd not showing elka_comm__common as a link dependency
# -> CommPort undefined symbol upon module import
target_link_libraries(
elka_comm__gnd_station
PUBLIC
elka_comm__common
)
set_target_properties(elka_comm__gnd_station PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${ELKA_BINARY_DIR}/python
)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS} ${GXX_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER__FLAGS} ${GCC_COVERAGE_LINK_FLAGS}")
add_dependencies(elka_comm__gnd_station
elka_comm__common
msg_gen
)
A few of my steps are redundant as sanity checks (e.g. setting flags w/CMAKE variables).
The following is the partial output of ldd -r <path-to-mod2.so>/mod2.so:
linux-vdso.so.1 => (0x00007fff777fe000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fadfe690000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fadfe479000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fadfe0b0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fadfddaa000)
/lib64/ld-linux-x86-64.so.2 (0x000055f1e6b2c000)
undefined symbol: _ZTIN4elka8CommPortE (build_elka_data_collection/python/elka_comm__gnd_station.so)
lib1 is called elka_comm__common.so, and so it should show up as a library dependency in ldd, right?
Partial output of cmake/make commands:
[100%] Linking CXX shared module ../../../python/elka_comm__gnd_station.so
cd /home/Programs/elka/elka_data_collection/build_elka_data_collection/src/elka_comm/gnd_station && /opt/cmake-3.4.3-Linux-x86_64/bin/cmake -E cmake_link_script CMakeFiles/elka_comm__gnd_station.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -fpic -Wno-as-needed -std=c++11 -fpic -Wno-as-needed -std=c++11 -g -shared -o ../../../python/elka_comm__gnd_station.so CMakeFiles/elka_comm__gnd_station.dir/pyelka_gnd_station.cpp.o CMakeFiles/elka_comm__gnd_station.dir/elka_devices.cpp.o `CMakeFiles/elka_comm__gnd_station.dir/inet_comm.cpp.o -L/home/Programs/elka/elka_data_collection/build_elka_data_collection/src/elka_comm/common -L/home/Programs/elka/elka_data_collection/build_elka_data_collection/src/elka_comm/gnd_station -L/home/Programs/elka/elka_data_collection/build_elka_data_collection/python -L/home/Programs/elka/elka_data_collection/python ../../../python/elka_comm__common.so -Wl,-rpath,/home/Programs/elka/elka_data_collection/build_elka_data_collection/src/elka_comm/common:/home/Programs/elka/elka_data_collection/build_elka_data_collection/src/elka_comm/gnd_station:/home/Programs/elka/elka_data_collection/build_elka_data_collection/python:/home/Programs/elka/elka_data_collection/python`
From this, it seems to me that linking is done correctly. My best intuition is that the ordering in the cmake generated link command is incorrect, but I can't justify this other than knowing that link commands are particular about ordering.
Solved by adding -Wl,--no-as-needed to CMAKE_CXX_FLAGS. Be mindful that adding to CMAKE_SHARED_LINKER_FLAGS|CMAKE_MODULE_LINKER_FLAGS doesn't work, and neither does adding -Wno-as-needed to CMAKE_CXX_FLAGS.
Other issues persist, though. If anyone is experienced w/binding c++ code to python pm me.
I have application built in Ubuntu 14.04 / GCC 4.8 / CMake 2.8 with -static-libgcc and -static-libstdc++. ldd command shows:
linux-vdso.so.1 => (0x00007ffc16195000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcb18256000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcb17f50000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb17b8a000)
/lib64/ld-linux-x86-64.so.2 (0x000055fc367e1000)
When I add -static to CMAKE_EXE_LINKER_FLAGS - I got different output from ldd:
linux-vdso.so.1 => (0x00007ffd48349000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe8d0335000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe8d0031000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe8cfd2a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8cf965000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055d61ec7d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe8cf74f000)
I supposed -static flag will result in static linked application. It did not happen.
May anyone explain me why ?
I have makefile generated by Qt Creator - with -static switch build results in fully static application.
-static is different from -static-libgcc and -static-libstdc++ specifically in that -static does not assume static linking of standard libraries. Those two flags control this behavior.
To link statically with standard libraries, add those two flags to CMake CMAKE_EXE_LINKER_FLAGS variable.
It is from resulting CMakeLists.txt. I use -DSTATIC_LINKING=True when running CMake.
IF(STATIC_LINKING)
SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
ENDIF(STATIC_LINKING)
# libpcap library
find_library(pcap libpcap.a)
# opencore-amr libraries
find_library(opencore-amrnb libopencore-amrnb.a)
find_library(opencore-amrwb libopencore-amrwb.a)
# c++ netlib
find_library(cppnetlib-server-parsers libcppnetlib-server-parsers.a)
find_library(cppnetlib-uri libcppnetlib-uri.a)
find_library(cppnetlib-client-connections libcppnetlib-client-connections.a)
# pthread
find_library(pthread libpthread.a)
# boost libraries
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
# set -static, when STATIC_LINKING is TRUE and set LINK_SEARCH_END_STATIC
# to remove the additional -bdynamic from the linker line.
IF(STATIC_LINKING)
SET(CMAKE_EXE_LINKER_FLAGS "-static -static-libgcc -static-libstdc++"
SET_TARGET_PROPERTIES(pvqa-server PROPERTIES LINK_SEARCH_END_STATIC 1)
ENDIF(STATIC_LINKING)
My cmake file is
cmake_minimum_required(VERSION 2.8.4)
project(libtry CXX)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(EXE_NAME libtry)
file(GLOB_RECURSE MAIN_SRC_FILES "src/*.cpp")
add_library (Try SHARED ${MAIN_SRC_FILES})
set(SOURCE_FILES main.cpp)
add_executable(${EXE_NAME} ${SOURCE_FILES})
target_link_libraries(${EXE_NAME} Try)
This file works and creates the two files: a .so file and an executable and it works perfectly. The problem is even after removing the .so file, the executable is working normally which means that the executable is statically linked.
Why this is happening and why cmake is not dynamically using the .so file?
Update
The dependencies by running ldd confirms this. Output of ldd is
linux-vdso.so.1 => (0x00007fffea5fe000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3585779000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3585563000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f358519c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3584e96000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3585aa7000)