5

I've got some problems with linking against a debug version of my lib. I use CMake to make a library:

project(myLib)
...
add_library(myLib SHARED ${SOURCES})

I launch the build two times to get a release and a debug version of my lib. Then I add 'd' suffix to the name of the debug lib and have myLib.dll and myLibd.dll.

In my app I explicitly link against the debug dll:

project(myApp)
add_executable(myApp WIN32 ${SOURCES})
target_link_libraries(myApp myLibd.dll)

The build finishes successfully, but when I open the resulting exe file with Dependency Walker I get an unresolved dependency to myLib.dll file, even though the debug version (myLibd.dll) is located in the same folder.

So, why does my app try to use the release version of my lib at runtime? And how do I properly link against the debug version?

Fraser
  • 74,704
  • 20
  • 238
  • 215
hank
  • 9,553
  • 3
  • 35
  • 50

1 Answers1

13

You should not rename the file manually. Use CMake's CMAKE_DEBUG_POSTFIX variable or the DEBUG_POSTFIX target property instead:

add_library(myLib SHARED ${SOURCES})
set_target_properties(mylib PROPERTIES DEBUG_POSTFIX "d")

[...]
add_executable(myApp WIN32 ${SOURCES})
target_link_libraries(myApp myLib)
ComicSansMS
  • 51,484
  • 14
  • 155
  • 166
  • Thanks, that worked. So I can't just rename my lib files to whatever I want and link against them? – hank Jul 26 '13 at 08:51
  • 1
    @hank Renaming the `.lib` will confuse CMake but you should still be able to compile and run the program. Renaming the `.dll` on the other hand will cause trouble as that name is [hardcoded in the import lib file](http://stackoverflow.com/questions/477461/when-building-a-dll-file-does-the-generated-lib-file-contain-the-dll-name). – ComicSansMS Jul 26 '13 at 09:01
  • @ComicSansMS how to do it under Linux? When I compile in release mode, the library is loaded at runtime. When it is compiled in debug mode, I get the "error while loading shared libraries" message. – madduci Aug 13 '14 at 08:41
  • @blackibiza The `DEBUG_POSTFIX` approach should work on Linux as well. You should open another question containing all the details of the problem you are encountering. – ComicSansMS Aug 13 '14 at 09:32
  • @ComicSansMS yes i had a problem with RPATH but now it's solved :) – madduci Aug 13 '14 at 12:15
  • What if we already have the DLL and just want to link against it (no access to source code or project for the library)? – rbaleksandar Sep 10 '21 at 13:38
  • @rbaleksandar In that case you should avoid renaming the library and instead deploy the debug and release versions to different directories and create an imported target for the lib with different locations for debug and release configs. If you insist on renaming the debug version, you need to write your own import library for it, which is a bit tedious but not very hard to do, even if you lost access to the original source code. – ComicSansMS Sep 12 '21 at 11:59
  • @ComicSansMS Indeed. I have decided to just do a file GLOB to retrieve the library (e.g. `file(GLOB LIBS "${DIR_TO_LIB}/myLib*.lib)"` for lib files, which are actually the ones required for the linking step on Windows) and just pass a variable that contains the values. Just like what one usually gets when using a `FindXYZ.cmake` and the respective `XYZ_LIBRARIES` variable. Renaming is indeed not an option. I've opened a lib file to verify and the DLL is indeed stored inside. – rbaleksandar Sep 13 '21 at 11:07