cmake: Add --no-undefined linker option

[hebasto]

This PR adds the --no-undefined option to a linker, which supports it.

From the GNU ld docs:

--no-undefined

Report unresolved symbol references from regular object files. This is done even if the linker is creating a non-symbolic shared library.

Closes #1556.

Looking for Concept (N)ACKs. Once ACKed, I'll add the same functionality to the Autotools-based build system.

[theuni]

Concept ACK.

I think we might be after -Wl,--no-allow-shlib-undefined, though, and only for the shared lib as that's what we care about. --no-undefined is strictly stronger, I guess, and should also be satisfied for the binaries. So I suppose the sledgehammer approach here should be fine.

[hebasto]

I think we might be after -Wl,--no-allow-shlib-undefined...

From my experience, it fails to catch an issue like one I demoed in #1556.

[real-or-random]

I think we might be after -Wl,--no-allow-shlib-undefined, though, and only for the shared lib as that's what we care about. --no-undefined is strictly stronger, I guess, and should also be satisfied for the binaries. So I suppose the sledgehammer approach here should be fine.

If https://stackoverflow.com/a/2356407 is right, then --no-undefined covers objects created by the linker and --no-allow-shlib-undefined covers shared libraries consumed by the linker.

[real-or-random]

Concept ACK

[hebasto]

Looking for Concept (N)ACKs. Once ACKed, I'll add the same functionality to the Autotools-based build system.

Added a commit for the Autotools-based build system.

[real-or-random]

I think we need to make add an exception to this if external default callbacks are enabled because the entire point of this option is that the user provides the callbacks at link time.

[hebasto]

I think we need to make add an exception to this if external default callbacks are enabled because the entire point of this option is that the user provides the callbacks at link time.

Right. I did it in CMake, but forgot about it in Autotools. Fixed.

[real-or-random]

Shouldn't this depend on the linker and not on the OS?

[hebasto]

I don't think it can be implemented in a simple way; see https://gitlab.kitware.com/cmake/cmake/-/issues/18209.

However, we can just check each variant.

[real-or-random]

Okay, I think checking CMAKE_SYSTEM_NAME is good enough and pragmatic. GNU ld doesn't even support the creation of macOS binaries, and even clang's macOS linker ld64.lld uses -fatal_warnings...

But shouldn't we append -Wl,-fatal_warnings or -Wl,--fatal-warnings also for the autotools build?