CLion: Enable debugging of external libraries by adding source files

Question

I am using CLion 2016.2.2 and I want to debug a method in the libtins library. However, it looks like the sources are not available because when trying to jump into the methods from libtins, the debugger does not go into and just updates the current view.

I tried to follow the suggestion in this post by adding include_directories("/home/patrick/libtins/") or include_directories("/home/patrick/libtins/src/")whereas libtins is the root folder cloned from the libtins repository. But CLion still could not find the source files associated to the libtins library.

My CMake file looks as follow:

project(myproject)

# Define CMake settings
cmake_minimum_required(VERSION 3.2)

IF(NOT CMAKE_BUILD_TYPE)
   SET(CMAKE_BUILD_TYPE "Release")
ENDIF()

IF (CMAKE_BUILD_TYPE MATCHES Debug)
    MESSAGE(STATUS "Running Debug configuration.")
ELSEIF (CMAKE_BUILD_TYPE MATCHES Release)
    MESSAGE(STATUS "Running Release configuration.")
ENDIF()

SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -Wall")
SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -Wall")

SET(CMAKE_CXX_STANDARD 11)
SET(CMAKE_CXX_STANDARD_REQUIRED ON)

# Add the library source files
SET(SOURCE_FILES cxx/myclass.cpp cxx/myclass.h)

# Include SQLiteCpp library and build it
option(SQLITECPP_RUN_CPPLINT OFF)
include_directories(SQLiteCpp/include)
add_subdirectory(SQLiteCpp)

# Find libtins library
FIND_LIBRARY(TINS_LIBRARY tins)
IF(TINS_LIBRARY)
  MESSAGE(STATUS "Tins library found in ${TINS_LIBRARY}")
ELSE()
  MESSAGE(FATAL_ERROR "Tins library not found.")
ENDIF()

FIND_PACKAGE(PythonLibs 3.0 REQUIRED)
IF(PYTHONLIBS_FOUND)
  INCLUDE_DIRECTORIES("${PYTHON_INCLUDE_DIRS}")
ELSE()
  MESSAGE(FATAL_ERROR "Unable to find Python libraries.")
ENDIF()

# Find and configure BOOST library
FIND_PACKAGE(Boost 1.54 QUIET)
IF (Boost_FOUND)
    INCLUDE_DIRECTORIES("${Boost_INCLUDE_DIRS}")
    SET(Boost_USE_STATIC_LIBS OFF)
    SET(Boost_USE_MULTITHREADED ON)
    SET(Boost_USE_STATIC_RUNTIME OFF)
    # Find the boost python 3 component
    SET(PYTHON_VERSIONS python3 python-py35 python-py34 python-py33 python-py32)
    FOREACH(VERSION ${PYTHON_VERSIONS})
      FIND_PACKAGE(Boost COMPONENTS ${VERSION} QUIET)
      IF(Boost_FOUND)
        MESSAGE(STATUS "Python Boost found as '${VERSION}'.")
        BREAK()
      ENDIF()
    ENDFOREACH(VERSION)
    IF(NOT Boost_FOUND)
      MESSAGE(FATAL_ERROR "Python Boost component not found.")
    ENDIF()
ELSE ()
    MESSAGE(FATAL_ERROR "Unable to find the Boost libraries (version 1.54 or higher).")
ENDIF ()

SET_target_properties(sqlite3 PROPERTIES POSITION_INDEPENDENT_CODE ON)

ADD_EXECUTABLE(myproject ${SOURCE_FILES} "/home/pjattke/libtins/")
TARGET_LINK_LIBRARIES(myproject ${Boost_LIBRARIES} "${TINS_LIBRARY}" SQLiteCpp sqlite3 pthread dl)

What exactly must I change to make CLion the source files available for debugging?

score 7 · Accepted Answer · answered Nov 16 '16 at 19:36

7

This might happen if libtins is built without debug info. How exactly do you build it?

It should be roughly the following:

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ../
make

answered Nov 16 '16 at 19:36

Eldar Abusalimov

24,387
4
67
71

score 3 · Answer 2 · answered Feb 28 '18 at 21:55

The following worked for me in Ubuntu 16.04.3 LTS with CLion 2017.3.3.

First you have to replace the CLion bundled gdb with Ubuntu's original (not sure why):

$ cd ~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/173.4548.31/bin/gdb/bin
$ mv gdb gdb_original
$ ln -s /usr/bin/gdb gdb

Then start the debugging session placing a breakpoint before stepping into library code.

When the execution is stopped at your breakpoint, go to the GDB console tab and execute this pointing to the full path where the source code to be debugged resides. For example, to debug OpenSSL's BIO_new function I had to do:

(gdb) dir /full/path/to/openssl-1.0.2g/crypto/bio

Because BIO_new is implemented in bio_lib.c which resides in the previous folder.

Now you can step into your library code.

Very helpful. I did not need to swap out the bundled gdb, but was able to get Clion to start using the source from the library. In doing this, I was able to add the source paths after I had stepped into a disassembly section...and then it flipped to source code on the next step. Thank you! — Gardener, Feb 05 '19 at 15:33

score 1 · Answer 3 · answered Jan 31 '17 at 11:56

The easiest way to do so is to build libtins directly in your project. Since libtins can also be built with CMake, the fastest way for you to do this is to add a directory called libtins in your source directory containing the libtins source, and include it in your project with

add_subdirectory(libtins)

For this you will need to fulfill the dependencies of libtins as well.

Then, you do not need FIND_LIBRARY(TINS_LIBRARY tins) anymore, since it is already present in your project. To link it the following should do the trick:

TARGET_LINK_LIBRARIES(myproject ${Boost_LIBRARIES} tins SQLiteCpp sqlite3 pthread dl)

Do not forget to include the tins directories beforehand:

include_directories(libtins/include/tins)

After this, when you run your program in debug mode, the libtins methods should also be available since it was built identically to your project.

Note that I would choose another strategy should you want to include libtins in your project in a long term. Then, I would rather look for a solution with the ExternalProject_Add command.

Seriously? The UL approved solution for debugging into external libraries (that have debug-info installed) is to build the library as part of your project? I'd hardly call that easy. I too have this problem with CLion - I've found that even if gdb can find the library sources, CLion still cannot. — John Calcote, Oct 23 '17 at 23:49
@JohnCalcote Building the library as part of your project makes sure you have the same compile flags as the other parts of your project (here, debug). So, yes, CLion will find it, and, yes, I'd call that easy. You cannot rely on debug-info to be installed in any case. — oLen, Oct 24 '17 at 06:16
@JohnCalcote is 100% correct. In most cases, it's crazy to suggest completely redoing an external build. Most projects have extremely complex build systems, and suggesting that you just casually drop it into your own build system isn't something that's realistic. — James Moore, Jan 25 '18 at 18:50

CLion: Enable debugging of external libraries by adding source files

3 Answers3