I need to enforce link order such that a library always appears first in the link command line.

Code
1

Mimalloc on Windows has a clever mechanism for overriding malloc calls via an interception mechanic, but in order for this to work, two libraries must be included first in the link order: mimalloc-redirect.lib and mimalloc-override.lib.

I’ve tried manually massaging LINK_LIBRARIES to force these two to be in the front, and I’ve also tried target_link_libraries(MyProj PRIVATE mimalloc Foo Bar) but in the resulting command line, Foo and Bar come first.

Any ideas? Is it simply a matter of forcing Foo to have a dependency on mimalloc, which I’ve pre-built and included as an interface library target.

2

If you need things to be first, that sounds like they should be object libraries rather than static libraries. That way, whatever symbols those objects provide will take precedence over anything from any libraries that might be linked in, including any libraries that the toolchain automatically adds (these don’t usually appear on the command line, but are added silently by the toolchain). Do you have the ability to compile the mimalloc libraries as object libraries instead?

3

Maybe defining an INTERFACE library for the mimalloc which links with all your application libraries (i.e. mimalloc depends on all libraries) will solve your problem:

add_library(mimalloc INTERFACE)
# specify mimalloc as first link libraries
target_link_libraries(mimalloc INTERFACE /path/to/mimalloc-redirect.lib /path/to/mimalloc-override.lib)
# add after all the user's libraries
target_link_libraries(mimalloc INTERFACE Foo Bar ...)

# and your application links only with mimalloc
target_link_libraries(MyProj PRIVATE mimalloc)
4

Unfortunately, I don’t think I can - the mimalloc-redirect.lib is prebuilt and packaged with the mimalloc distribution, there’s no way I can build it inline as part of the overall project, which is what I think you have to do with an object library.

5

This is interesting but it would require significant rework of our overall project structure because we include third party libraries via add_subdirectory() before Foo and Bar get added as library targets. I can certainly try this as an experiment to see if it would work.

6

The fact that it is for all libraries makes me feel like this belongs as part of the toolchain configuration or project-wide flags (though I think these come after target-specific flags).

7

Hi, I’m having the exact same issue. One thing I’ve seen is that in some cases simply adding mimalloc to target_link_libraries is enough for CMake to link it before any other library, including system libs. However, this doesn’t seem to happen in all cases. @ben.boeckel is target_link_libraries guaranteed to honor the link order passed to it, so that the libs will appear even before any system libs?

8

I think this issue is of interest for history. The results of it are the LINK_LIBRARIES_STRATEGY property and policy CMP0179 (which depends on CMP0156).

9

Thanks @ben.boeckel , I’ll take a look.

10

So I’ve looked at this further. I’m using CMake 3.29 on Windows, which is correctly generating linker invocations with mimalloc first (as specified in target_link_libraries); however in my case I had an .exe which had mimalloc first in target_link_libraries but itself didn’t include any mimalloc symbols. However, the .exe was also linked against a static library which did include mimalloc symbols. The result was that even though CMake was generating the correct linker invocation, the linker itself ended up placing mimalloc at the end of the dependency list (as reported by dumpbin /DEPENDENTS).

The solution for me was to force-include a mimalloc symbol on the .exe itself (as stated in mi-malloc: Overriding Malloc). Doing that seems to have fixed the issue, and now mimalloc appears first.