SetupBuildFlags.cmake filters out necessary LDFLAGS from environment with clang
My LDFLAGS is as follows:
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-zpack-relative-relocs -flto=thin -Wl,--defsym=__gentoo_check_ldflags__=0"
However when compiling evolution-ews, it filters out most of that, including the rather important -Wl,--as-needed and other things that should work fine, while adding a -Wl,--no-undefined
which is then ignored by my linker (lld) in the first place.
-- The C compiler identification is Clang 17.0.6
Linker flags:
Executable -Wl,--no-undefined -Wl,-zpack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0
Module -Wl,--no-undefined -Wl,-zpack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0
Shared -Wl,--no-undefined -Wl,-zpack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0
This doesn't happen with GCC, presumably because SetupBuildFlags.cmake is doing all that, which applies some LDFLAGS overrides for --no-undefined addition only when the compiler is clang or gcc on BSD (but not on linux).
I'm not 100% sure it's SetupBuildFlags.cmake
causing this, but feels like it might as the problem doesn't happen with GCC and in there it does things only for clang.
Given that --no-undefined will even be fully ignored, I question the whole thing in the first place. Like shouldn't it be based on linker then or something? What's it even trying to achieve there?
This probably affects all evolution modules, not just evolution-ews, but due to this we couldn't launch gnome-contacts on clang-using systems. See gnome-contacts#222 (comment 2037204) and onwards for more details.