CMAKE building static executable instead of using dynamic library - c++

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)

Related

GTest cannot load imported share library

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?

Unable to statically link executable with CMake [duplicate]

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)

Dynamic linking of QT in WSL not working but working in docker container

I want to build a c++ program that dynamically links the QT-Core library.
For this I am using the WSL as my build environment and CLion as my IDE.
When I compile this programm in the WSL (ubuntu_18.04) the linker does not find the QtLibrary but when I compile it in a docker container (ubuntu_18.04) the linker finds the library.
I am quite confused by this since it seems to me I have set the library search path correctly.
Anyone got any idea what might be causing this ?
My project structure is the following:
apps
- CMakeLists.txt
- main.cpp
extern
- qt-linux
src
- CMakeLists.txt
- functions.cpp
- functions.hpp
toolschains
- linux-toolchain.cmake
CMakeLists.txt
build.sh
The CMakeLists.txt files look like this:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
project(cpp_hello_world)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/Install)
set(CMAKE_SKIP_BUILD_RPATH FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
# QT SETUP
if(UNIX)
set(Qt5Core_DIR "extern/qt-linux/lib/cmake/Qt5Core")
install(DIRECTORY ${PROJECT_SOURCE_DIR}/extern/qt-linux/lib/ DESTINATION
lib)
endif()
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
find_package(Qt5Core)
add_subdirectory(src)
add_subdirectory(apps)
src/CMakeLists.txt:
set(CMAKE_INCLUDE_CURRENT_DIR ON)
add_library(HelloLibrary SHARED functions.hpp functions.cpp)
target_link_libraries(HelloLibrary Qt5::Core)
target_include_directories(HelloLibrary PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
install(TARGETS HelloLibrary DESTINATION lib)
install(FILES functions.hpp DESTINATION include)
apps/CMakeLists.txt:
add_executable(hello-world main.cpp)
target_link_libraries(hello-world HelloLibrary)
target_link_libraries(hello-world -static-libgcc -static-libstdc++)
install(TARGETS hello-world DESTINATION bin)
and I build using the following build.sh script:
#!/bin/bash
export SOURCE_DIR=$(pwd)
rm -R build
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../toolchains/linux-
toolchain.cmake -G "CodeBlocks - Unix Makefiles" ${SOURCE_DIR}
make
make install
ldd output WSL:
linux-vdso.so.1 (0x00007ffff62d6000)
libHelloLibrary.so => /mnt/c/Users/ci/Documents/Development/cpp-cmake-prototype/Install/bin/../lib/libHelloLibrary.so (0x00007f7c96fb0000)
libQt5Core.so.5 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7c96bb0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7c97600000)
libQt5Core.so.5 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7c96820000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7c965f0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7c96250000)
ldd output Docker-Container:
linux-vdso.so.1 (0x00007ffc6932a000)
libHelloLibrary.so => /Install/bin/./../lib/libHelloLibrary.so (0x00007f36411db000)
libQt5Core.so.5 => /Install/bin/./../lib/libQt5Core.so.5 (0x00007f3640c33000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3640842000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3641715000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f36404b9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f36402a1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3640082000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f363fe65000)
libicui18n.so.60 => /usr/lib/x86_64-linux-gnu/libicui18n.so.60 (0x00007f363f9c4000)
libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f363f60d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f363f409000)
libdouble-conversion.so.1 => /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.1 (0x00007f363f1f8000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f363eee2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f363eb44000)
libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f363cf9b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f363cd29000)
I figured this one out now
The problem was the libQt5Core.so.5 was build with .note.ABI-tag set to a version incompatible with what the WSL identifies as(4.4) but the docker container was compatible(4.9).
Similar to what happens here:
https://github.com/Microsoft/WSL/issues/3023

Link Linux C++ application statically via CMake 2.8

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)

CMAKE, SDL2 and OPENGL: Program binary is too big

I use CMAKE to link a program to SDL2, OpenGL and I compile tinyxml2 as a shared library. The resulting program binary is 1.4 mb but there's barely 1k lines of code in the program. I suspect some library is statically linked. I'd prefer they are linked as shared libraries. I tried with debug symbols on and off with:
cmake -DCMAKE_BUILD_TYPE=Debug .
and off:
cmake .
and resulting binaries are still 1.4 mb each, which is weird because debug should be bigger. Here is my CMakeLists.txt:
project(ProjectName)
cmake_minimum_required(VERSION 2.8)
set(CMAKE_CXX_FLAGS "-Wall -std=c++11")
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake-find-scripts")
aux_source_directory(. SRC_ROOT)
aux_source_directory(./extlib SRC_EXTLIB)
aux_source_directory(./engine SRC_ENGINE)
aux_source_directory(./utils SRC_UTILS)
include_directories(./extlib)
include_directories(./engine)
include_directories(./utils)
include_directories(${SDL2_INCLUDE_DIR})
include_directories(${OPENGL_INCLUDE_DIRS})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR})
set(LONE_HEADERS ./engine/stc_config.h)
add_executable(${PROJECT_NAME} ${SRC_ROOT} ${SRC_ENGINE} ${SRC_UTILS} ${LONE_HEADERS})
find_package(SDL2 REQUIRED)
find_package(SDL2IMAGE REQUIRED)
find_package(OpenGL REQUIRED)
add_library(tinyxml2 SHARED ./extlib/tinyxml2.cpp)
target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARIES} ${OPENGL_LIBRARIES} ${SDL2IMAGE_LIBRARIES} tinyxml2)
Edit: I've checked which library files the binary is linked with using ldd command and the output confirms they are all shared libraries:
linux-vdso.so.1 (0x00007fff9dbf0000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f3accff7000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f3accdda000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f3accb59000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f3acc7fb000)
libSDL2_image-2.0.so.0 => /usr/lib/libSDL2_image-2.0.so.0 (0x00007f3acc5d5000)
libtinyxml2.so => /home/hacow/OGLTEST/libtinyxml2.so (0x00007f3acc3bd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3acc0ae000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f3acbda9000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f3acbb93000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f3acb7f0000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f3acb5ec000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f3acb3e4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3acd2fa000)
libnvidia-tls.so.349.16 => /usr/lib/libnvidia-tls.so.349.16 (0x00007f3acb1e1000)
libnvidia-glcore.so.349.16 => /usr/lib/libnvidia-glcore.so.349.16 (0x00007f3ac8472000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f3ac8130000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f3ac7f1e000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f3ac7cfc000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f3ac7af8000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f3ac78f2000)
Building with cmake . uses the same CMAKE_BUILD_TYPE as the most recent build in that directory. Use cmake -DCMAKE_BUILD_TYPE=Release . to build in release mode. If you built debug first then release, using the procedure you described, it would just rebuild your debug binary.