# Unexpected behavior of TARGET\_RUNTIME\_DLLS when mixing STATIC, SHARED, PUBLIC, PRIVATE libraries

**URL:** https://discourse.cmake.org/t/unexpected-behavior-of-target-runtime-dlls-when-mixing-static-shared-public-private-libraries/10352
**Category:** Usage
**Tags:** os:windows, comp:msvc, gen:ninja, tool:cmake
**Created:** [March 13, 2024, 10:06am UTC](https://discourse.cmake.org/t/unexpected-behavior-of-target-runtime-dlls-when-mixing-static-shared-public-private-libraries/10352 "2024-03-13T10:06:44Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![rkoning](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rkoning/32/4399_2.png) [@rkoning](https://discourse.cmake.org/u/rkoning)
#### Post date: [March 13, 2024, 10:06am UTC](https://discourse.cmake.org/t/unexpected-behavior-of-target-runtime-dlls-when-mixing-static-shared-public-private-libraries/10352/1 "2024-03-13T10:06:44Z")

</div>

I’m running into some unexpected behavior when using the TARGET\_RUNTIME\_DLLS generator expression, and I’m wondering if this is something that I’m just not understand properly or if its an unhandled edge case that I should raise an issue for.

I have narrowed it down to the following minimal example:

```auto
cmake_minimum_required(VERSION 3.21)

project(target_runtime_dlls_test)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED true)

add_library(dll_2 SHARED dll_2.cpp)

add_library(lib STATIC lib.cpp)
target_link_libraries(lib PRIVATE dll_2)

add_library(dll_1 SHARED dll_1.cpp)
target_link_libraries(dll_1 PRIVATE lib) # making this PUBLIC fixes the dll listing

add_executable(executable main.cpp)
target_link_libraries(executable PRIVATE dll_1)

add_custom_target(executable _dlls
    COMMAND "${CMAKE_COMMAND}" -E echo "$<TARGET_RUNTIME_DLLS:executable >"
)

```

With these dependencies `dll_2` is not shown in the list of TARGET\_RUNTIME\_DLLS for the executable. Changing the dependency so that the dependency on `lib` is PUBLIC “fixes” this behavior, but doing so is undesirable as it also exposes other details that should remain private. It is my understanding that the PUBLIC/PRIVATE relationship is a compile- and link-time concept, so I was not expecting it to affect a runtime feature in this manner.

Is the behavior I’m seeing expected, or should I raise an issue for this?

---

<div class="post-metadata">

### Author: ![fdk17](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/f/ea666f/32.png) [@fdk17](https://discourse.cmake.org/u/fdk17)
#### Post date: [March 16, 2024, 2:09pm UTC](https://discourse.cmake.org/t/unexpected-behavior-of-target-runtime-dlls-when-mixing-static-shared-public-private-libraries/10352/2 "2024-03-16T14:09:18Z")

</div>

After reading the documentation I think this should work. I’d open an issue.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 10, 2024, 10:05pm UTC](https://discourse.cmake.org/t/unexpected-behavior-of-target-runtime-dlls-when-mixing-static-shared-public-private-libraries/10352/3 "2024-04-10T22:05:42Z")

</div>

I agree, [an issue](https://gitlab.kitware.com/cmake/cmake/-/issues/new) seems warranted.

Cc: @kyle.edwards