Home/ Questions/Q 3756502
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T09:51:43+00:00

Related to using cmake to link object files into lib.xxxx.a file , but not

  • 0

Related to using cmake to link object files into lib.xxxx.a file, but not quite the same thing, I have built several static libraries on Windows using CMake 2.8.x using VS2008 SP1. Is there a way via CMake alone to relink all of the .obj files inside all of those existing static libraries into one larger monolithic library, preferably via the add_library CMake function, or other similar construct?

I think the answer is “no”, and so I have thought about rolling my own via a custom command via the usual add_custom_command + add_custom_target approach, that simply constructs the library manually, by supplying all of the other libraries .obj files when calling LINK.EXE. But I see some problems with that approach:

  1. I could not find a CMake variable that indicates the fully-qualified path to the LINK.EXE executable. I would then have to somehow derive the path to LINK.EXE using a fragile heuristic: It is fragile in the sense that different Visual Studio versions may locate the LINK.EXE file in different directories, and I’m needing this to work for both 32-bit and 64-bit Windows compiler conditions, and be resilient against upgrades between VS2008 and future compiler revisions.
  2. I would have to find a way to find all of the .obj files of the other static libraries, at build time versus at CMake time, since at CMake time the .obj files of course do not (always) exist. For reasons of build performance, I desire not to resort to extracting the .obj files from the .lib files for the sake of adding them to the LINK.EXE command line, so a FILE(GLOB...) construct would be my best second alternative in this case.
  3. It may be possible to simply call LINK.EXE via: LINK.EXE /OUT:monolithic.lib lib1.lib lib2.lib ..., but maybe not all .obj’s will be included (EDIT: I have confirmed that LINK.EXE omits some .obj files from lib1.lib lib2.lib ... without any diagnostic messages explaining why, so this approach is a non-starter); the online docs for LINK.EXE are unclear as to that point. Anyone have any experience with using LINK.EXE in that manner?

Thanks,

Brent

P.S., I know how to create a DLL using CMake, but I specifically do not want to resort to building a DLL at this point in time.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Create a static library “merged” with a dummy source file, and add libs to be merged to the STATIC_LIBRARY_FLAGS, so they will be additional input to lib.exe.

    This would be something like:

    ADD_LIBRARY(merged STATIC dummy.c)

    SET_TARGET_PROPERTIES(merged PROPERTIES
    STATIC_LIBRARY_FLAGS “full\path\to\lib1.lib full\path\to\lib2.lib”)

    This approach is used inside MySQL, there is a more general macro here to merge static libraries that works crosss-platform. It can be found here http://www.mail-archive.com/cmake@cmake.org/msg28670/libutils.cmake

    • 0