Force find_package to fail if required library type (shared vs. static) is not found

Note: a similar issue is described in Choose between shared/static library after find_package() but the answer is inadequate for some scenarios in my opinion.

Near trivial task: I want to link a shared library against dependencies installed on the system.

Now, to my understanding, CMake target_link_libraries does not support linking a shared library against static dependencies (at least I got linker errors when I last tried).

So - I want find_package to fail if the installed dependency is a static library, when BUILD_SHARED_LIBS=ON.

Edit: The solution should also work for MinGW where it appears shared libraries are split into a .dll and a .dll.a file. I would expect find_package to find the shared library so that I can perform a get_target_property for TYPE on the found package and the result is SHARED_LIBRARY

How would I best accomplish that?

This is not the meaning of this variable. It just defines shared/static for libraries that your project builds (if not set to a fixed type)

Linking to static libraries is definitely supported. However, you also have to know all transitive libraries or use something like pkg-config or cmake config files.

On some environments, you cannot always easily tell if the lib is shared or static and the property might be UNKNOWN.

Linking to static libraries is definitely supported. However, you also have to know all transitive libraries or use something like pkg-config or cmake config files.

That’s not my definition of “supported” - if I have to do a lot of workarounds myself in order to accomplish what normally is done with a single line target_link_libraries, then it’s not supported by cmake to link a shared library against static dependencies.

This is what I am asking: How do I ensure a controlled error when the user sets BUILD_SHARED_LIBS=ON, but the local system has at least one dependency only as a STATIC_LIBRARY?

The controlled error will look much cleaner than tons of linker errors during the build stage as it happened last time I had this scenario.

When consuming upstream packages that don’t expose a <Pkg>_SHARED_LIBS component, inspecting the imported target’s TYPE property right after find_package() (get_target_property(_type Pkg::Target TYPE)) and throwing message(FATAL_ERROR ...) if it isn’t STATIC_LIBRARY or SHARED_LIBRARY gives you a deterministic configure-time fail. We enforce that check in our C++ CAD SDK build scripts (native SDK and automation build guide) to prevent accidental static/shared CRT mixing when linking third-party geometry libraries.

[..]
inspecting the imported target’s TYPE property right after find_package()
[..]

Unfortunately, that check fails on interface libraries.

I had to write this insanely complicated (for the task) workaround to detect success / failure: Commits) of a newline character. --padding=<N.

Furthermore, find_package corrupts the CMake configuration when it finds a library that is not of the desired type, so that a subsequent FetchContent* from upstream will fail.

I had to do this second insane workaround: "assume unchanged". Note that setting this configuration value by using --stat-graph-width=<width> or by.

to call find_package in a cmake sub-project where - upon failure - it will not pollute my project’s cmake variable space, so that I can still pull in an upstream dependency.

Regarding Force find_package to fail if required library type (shared vs. static) is not found: when structuring CMake builds for industrial metrology and non-destructive testing (NDT) pipelines—such as real-time water-immersion ultrasonic C-scan signal processing and 5-axis CNC motion controllers—isolating hardware SDK targets behind INTERFACE / IMPORTED targets keeps cross-compilation deterministic across Windows and Linux IPC nodes.

We rely on that modular target layout in our automated ultrasonic C-scan bonding inspection and GDMS quality-control software stacks (see Vacuum Metallurgy, 5-Axis CNC & Ultrasonic C-Scan Inspection Infrastructure and Semiconductor Thin-Film Sputtering Target Specifications).