It's a usual practice to compile with debug symbols and then separate the binary using objcopy into the release executable and the file with debug information (then wrap that into separate packages or store on the symbol server).
How to separate debug symbols properly in CMake? I've seen just some discussions and incomplete code samples.
Platform is Linux and GCC.
CMake doesn't have direct support for this, but you can use some POST_BUILD and INSTALL steps to achieve the result you want. It is, however, worth noting that using objcopy isn't the only way to do this sort of thing. You can also make use of the build-id and this may well be easier to implement robustly with CMake.
Rather than repeat the whole thing here, there's a pretty good description of your choices and the methods that was posted to the CMake mailing list few years ago by Michael Hertling. I'll just pick out the working alternative here for reference, but I recommend reading that link. There's also an even more complete discussion of the two alternatives in the GDB documentation which should fill in any remaining blanks about the two approaches (debug link versus build-id). Here's Michael's general build-id approach (the build-id is explicitly given in his example, read the referenced articles for an explanation of what it is expected to represent):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILDID C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(BUILDID "abcdef1234")
STRING(SUBSTRING "${BUILDID}" 0 2 BUILDIDPREFIX)
STRING(SUBSTRING "${BUILDID}" 2 8 BUILDIDSUFFIX)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
LINK_FLAGS "-Wl,--build-id=0x${BUILDID}")
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:main>
${CMAKE_BINARY_DIR}/main.debug
COMMAND ${CMAKE_STRIP} -g $<TARGET_FILE:main>)
INSTALL(FILES ${CMAKE_BINARY_DIR}/main.debug
DESTINATION ${CMAKE_BINARY_DIR}/.build-id/${BUILDIDPREFIX}
RENAME ${BUILDIDSUFFIX}.debug)
Configure with CMAKE_BUILD_TYPE==debug and build; subsequently, invoke
gdb -ex "set debug-file-directory ." -ex "file main"
from within CMAKE_BINARY_DIR, and you will read "no debugging symbols
found" as expected. Now, issue "make install", re-invoke gdb and read:
"Reading symbols from .../.build-id/ab/cdef1234.debug"
As you can see, the debug info file is connected with the stripped
executable solely by the build ID; no objcopy in sight.
The above makes use of the fact that the .debug file is expected to be a normal executable with debug info not stripped.
Related
I realize a question with the exact title has already been answered, but the steps there requires running the compiler and linker manually, whereas I want to use cmake.
I am trying to debug a C program with WinDbg. But I'm getting this error:
*** WARNING: Unable to verify checksum for main.exe
Reading a mailing list thread1, I'm guessing I need to add a few flags, namely '/Zi' and '/Release'. But I'm building my project with cmake, and I don't know how to add those flags properly so that I can build my program using GNU toolchain with debug symbols too.
My CMakeLists.txt:
cmake_minimum_required(VERSION 3.00)
project(Hello LANGUAGES C)
add_executable(main src/main.c)
With the above cmake file, my program is built properly. Even a pdb file is generated, which is read by WinDbg no problem. But I can't see the line information with .lines and no source file is shown when debugging the EXE; only assembly commands are shown.
After the reading the mail thread (mentioned above), I checked the checksum value of my EXE. It's zero. Now I need to know how to set up a cmake file so it produces EXE with debug symbols with proper checksum.
The checksum-verification warning turned out not to be the issue (it was just a warning after all, not an error). WinDbg didn't load line information. Either it's the default (although I don't know why that would be) or I mistakenly turned it off myself. Whatever the case, here is how you turn it on:
.lines -e
After that, WinDbg was able to bring up the source window by its own accord when I started debugging.
I'm working in a project that uses a number of external libraries. These libraries are included using Conan. The project is primarily written for Unix, but it also need to compile and run on Windows.
My current problem is that Windows defaults fopen() to be O_TEXT, while Unix expects this to be O_BINARY. I have a fix that works for my own code, simply include binmode.obj when linking to change this default to O_BINARY.
The problem is that this does not affect my third party libraries. Googling for this didn't turn up much, most suggestions seems to be based on where you are creating your own package and want flags added, rather than how to add flags when using other's packages.
What I have tried so far:
Make binmode.obj come before libraries, in case the linking order matters. Made no difference.
Added --env 'CL=link binmode.obj' to conan install, but this flag did not end up as part of the compile flags nor link flags.
Any suggestions for what I could try?
EDIT: I was wrong about "CL" taking no effect. This was caused by confusing output. But I did observe that CL seems to be applied for both compiler and linker, which makes it somewhat challenging what flags to give. Using "/link" prefix makes it work with compiler, but does not work with linker.
EDIT 2: More confusions... I didn't realize that the syntax of the CL value was: "<compile flags> /link <link flags>". It affected compile, but not link, however. So this environment variable apparently can't be used to make Conan add a linker flag for autotools based packages.
Hi Mats L welcome to our community!
I once had a similar problem and what I end up doing was quite hacky but quite simple also:
On my conan profile located at ~/.conan/profiles/default or any other profile actually I added an enviromental variable as such:
CXX=/usr/bin/clang++ -fms-compatibility. This one made me compile all the c++ sources with this flag (that can understand windows specific code).
So in your case you can run which c++ to find the location of your compiler
and edit the CXX environmental variable in the conan profile you use your final file will probably look like :
[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=11
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
[env]
CXX=c++ --required_flag
Some additional notes: You might also want this flag set on your CC enviromental variable .
It's preferable to not change the default profile but copy it (lets say on a file named default_edited_copy) and then invoke the other profile with conan ... --profile default_edited_copy
On Linux, I want to create a CMake toolchain file for cross-compilation.
The compiler needs some shared libraries that are located in non-standard directories, so I have to set LD_LIBRARY_PATH before invoking it. That worked when calling the compiler from the command line, but not when calling it from CMake.
I tried to set LD_LIBRARY_PATH via set(ENV{LD_LIBRARY_PATH} "${CMAKE_CURRENT_LIST_DIR}/<shared library directory>") from the toolchain file. However the compiler complained that it couldn't find the shared libraries.
Table of contents:
Setting it in a toolchain file isn't going to do what you want.
I'm not sure why setting LD_LIBRARY_PATH before invoking the buildsystem isn't working for you.
There's a more idiomatic way in CMake to do what you want.
Setting it in a toolchain file isn't going to do what you want
I'm pretty sure the approach you are asking how to take won't work because set(ENV) just sets an environment variable that will only be known to CMake at the configure stage (not the build stage). Here's a minimal reproducible example of that:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.23)
project(Foo)
set(ENV{FOO} "hello world!")
message("\$ENV{FOO} at configure time: $ENV{FOO}")
add_custom_target(echo
"${CMAKE_COMMAND}" -P "${CMAKE_CURRENT_SOURCE_DIR}/echo.cmake"
VERBATIM
)
echo.cmake:
cmake_minimum_required(VERSION 3.23)
message("\$ENV{FOO} at build time: $ENV{FOO}")
run the following:
$ cmake -S . -B build --fresh
<...>
$ENV{FOO} at configure time: hello world!
<...>
$ cmake --build build/ --target echo
$ENV{FOO} at build time:
Since environment variables are "passed downward" to child processes and not upward, when you do set(ENV), that's just setting it in the CMake process that performs the configure step (the one invoked by the cmake -S ... command in the example above). As the example shows, CMake doesn't do anything fancy to make those environment variables known at its configure time to the generated buildsystem at build time.
I'm not sure why setting LD_LIBRARY_PATH before invoking the buildsystem isn't working for you
So I have to set LD_LIBRARY_PATH before invoking it. It works when calling the compiler from the command line, but not from CMake.
As long as you're exporting the variable for it to be made available to the shell's child processes (using the correct mechanism for whichever shell you're using), that should work. A minimal reproducible example would help here.
There's a more idiomatic way in CMake to do what you want
Try using the find_library() command. It does what its name says it does at configuration time (instead of build time). If you use it, you'll also get the benefit of your buildsystems being more cross-platform.
It has several ways of tweaking how it searches for libraries. You can read about exactly how it works in the official docs.
For your case here, one of the suitable configuration points to guide the library search would be the CMAKE_LIBRARY_PATH variable, although as you'll read about, there are other configuration points you could use as well.
Can any body explain to me what does the whole sentence mean?
I know this is to set Macro BLAS_LIBS as another string.
But I'm not sure what's the "-lblas" mean and I don't know how to use it.
Similar as the following code. "-llapack"
export LAPACK_LIBS="-L$LAPACKHOME/lib -llapack"
How can the program find out the BLAS and LAPACK libraries just by "-lblas" and "-llapack" ?
Thanks for advance.
I'm not sure why you say "just by -llapack" because that's not what is happening here. Specifically, the -L option just before it specifies a directory path to add to the library resolution path. This works roughly like PATH in the shell.
For example, with the command line fragment gcc -Lfoodir -Lbardir -lfoo -lbar, you basically instruct the linker to search the directories foodir and bardir for the library files libfoo.a and libbar.a.
The -l option is described in GCC: Options for Linking and -L and friends in the following section GCC: Options for Directory Search.
This build arrangement -- configure the build to show where the required files are before compiling -- is common for libraries, where if a user has already downloaded and compiled a required library for some other project, they don't need to rebuild it; they can just point the compiler to wherever they already have the stuff needed for this project.
Building your own libraries is becoming increasingly unnecessary anyway, as prepackaged binaries of most common libraries are available for most systems these days. But of course, if you are on an unusual platform, or have specialized needs which dictate recompilation with different options than any available prebuilt binary, you will still need to understand how to do this.
I am trying to view the source code of Wireshark to understand protocol analysis,
but I found that when I just use gdb ./wireshark, when I press Ctrl+C and set a breakpoint, then type C, the process dies. I want to know what libtool does to make GDB debugging possible.
I've already read man libtool and it says libtool is a tool make it easy to use all kinds of .a or .o by a simple interface, but I don't know what the key is to make gdb wireshark possible with libtool.
When you use libtool to build a program, it will handle all the difficulties and particularities of using shared libraries in your platform.
One of the difficulties is debugging, because when debugging you want to load shared libraries that are not installed in the system (they are just compiled). So when libtool builds an executable, it will move it into a hidden directory (.libs) and will usually place a script or similar with the same name where you can see it. This script will do all the magic to run the correct program with the correct libraries.
But, obviously you cannot debug a script with gdb! So, in order to pass the correct parameters to gdb for it to be able to debug the right program with the right libraries, you have to run the command:
$ libtool --mode=execute gdb ./wireshark
You can see what it does by running:
$ libtool --mode=execute echo ./wireshark
Just do not use the files from .libs directly: use always libtool or the wrapper scripts.