OpenBSD has a similar patch inside the ports, see

Allow KDE5 libraries to be built without having to link to libc explicitly.
Index: kde-modules/KDECompilerSettings.cmake
--- kde-modules/KDECompilerSettings.cmake.orig
+++ kde-modules/KDECompilerSettings.cmake
@@ -530,6 +530,8 @@ endfunction()
 # Better diagnostics (warnings, errors)
 ############################################################

+set(ALLOW_UNDEFINED_LIB_SYMBOLS No CACHE BOOL "allow undefined symbols in generated shared objects")
+
 if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPLE) OR
         (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT APPLE) OR
         (CMAKE_CXX_COMPILER_ID STREQUAL "Intel" AND NOT WIN32))
@@ -537,9 +539,11 @@ if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPL
     set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_SHARED_LINKER_FLAGS}")
     set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_MODULE_LINKER_FLAGS}")

-    # Do not allow undefined symbols, even in non-symbolic shared libraries
-    set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
-    set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+    if (NOT ${ALLOW_UNDEFINED_LIB_SYMBOLS})
+        # Do not allow undefined symbols, even in non-symbolic shared libraries
+        set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
+        set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+    endif()
 endif()

 set(_KDE_GCC_COMMON_WARNING_FLAGS "-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef")

If the module is not included, the current message would be misleading.

Including the module by default is undesirable, because we print out a warning
that we do not override an existing module. While this warning is reasonable in most
cases, it is annoying for projects that have a custom clang-format file.

Checking if a .clang-format file exists and if not including KDEClangFormat is fragile,
because it depends on the include order of the modules.

Considering all that, a proper warning with instructions on how to fix the issue
is IMHO the best way to go.

I was getting CMake errors in repositories that had a pre-existing commit
hook: `string sub-command FIND requires 3 or 4 parameters.`
Adding quotes around the variables from 6224e7b8c28d434b81a19ac47b88cb58fee9d7d5
fixes this issue for me.

If the .git/hooks/pre-commit already exists, only add the clang-format line
if it doesn't already exist.

If clang-format isn't found, there is nothing to write to the file.

Continuation of commit 4e47b053c9d799.

All unittests still pass.

It should be --extensions "cpp,h,hpp,c"; previously, I naively tested that
it didn't bother .json files, but I not if it'll actually trigger for e.g.
a .h file...

Previously the clang-format.sh git hook script didn't specify the file
extensions to format; however it looks like with recent(?) clang-format
versions 'git clang-format' will consider .json files if such files were
changed by a commit, which makes the script fail, see:
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/254

Sepcify the file extensions by passing --extensions to 'git clang-format'
command.

Also add ".hpp" to the file extensions we format, and use the same list of
file extensions everywhere.

If we are not tracking a specific branch, assume the remote is "origin"
which is git's default.