# LINK_LIBRARIES_STRATEGY

Added in version 3.31.

Specify a strategy for ordering a target's direct link dependencies on linker command lines. This property is initialized by the value of the `CMAKE_LINK_LIBRARIES_STRATEGY` variable if it is set when a target is created.

CMake generates a target's link line using its Target Link Properties. In particular, the `LINK_LIBRARIES` target property records the target's direct link dependencies, typically populated by calls to `target_link_libraries()`. Indirect link dependencies are propagated from those entries of `LINK_LIBRARIES` that name library targets by following the transitive closure of their `INTERFACE_LINK_LIBRARIES` properties. CMake supports multiple strategies for nominally ordering direct and indirect link dependencies, which are then filtered for Toolchain-Specific Behavior.

Consider this example for the strategies below:

    add_library(A STATIC ...)
    add_library(B STATIC ...)
    add_library(C STATIC ...)
    add_executable(main ...)
    target_link_libraries(B PRIVATE A)
    target_link_libraries(C PRIVATE A)
    target_link_libraries(main PRIVATE A B C)

The supported strategies are:

`REORDER_MINIMALLY`

  Entries of `LINK_LIBRARIES` always appear first and in their original order. Indirect link dependencies not satisfied by the original entries may be reordered and de-duplicated with respect to one another, but are always appended after the original entries. This may result in less efficient link lines, but gives projects control of ordering among independent entries. Such control may be important when intermixing link flags with libraries, or when multiple libraries provide a given symbol.

  This is the default.

  In the above example, this strategy computes a link line for `main` by starting with its original entries `A B C`, and then appends another `A` to satisfy the dependencies of `B` and `C` on `A`. The nominal order produced by this strategy is `A B C A`.

  Note that additional filtering for Toolchain-Specific Behavior may de-duplicate `A` on the actual linker invocation in the generated build system, resulting in either `A B C` or `B C A`.

`REORDER_FREELY`

  Entries of `LINK_LIBRARIES` may be reordered, de-duplicated, and intermixed with indirect link dependencies. This may result in more efficient link lines, but does not give projects any control of ordering among independent entries.

  In the above example, this strategy computes a link line for `main` by re-ordering its original entries `A B C` to satisfy the dependencies of `B` and `C` on `A`. The nominal order produced by this strategy is `B C A`.

## Toolchain-Specific Behavior

After one of the above strategies produces a nominal order among direct and indirect link dependencies, the actual linker invocation in the generated build system may de-duplicate entries based on platform-specific requirements and linker capabilities. See policy `CMP0156`.

For example, if the `REORDER_MINIMALLY` strategy produces `A B C A`, the actual link line may de-duplicate `A` as follows:

- If `A` is a static library and the linker re-scans automatically, the first occurrence is kept, resulting in `A B C`. See policy `CMP0179`

- If `A` is a shared library on Windows, the first occurrence is kept, resulting in `A B C`.

- If `A` is a shared library on macOS or UNIX platforms, the last occurrence is kept, resulting in `B C A`.