pkgsStatic.stdenv: fix custom CMake LINKER_LANGUAGE

If a CMake target has a non-default LINKER_LANGUAGE set, CMake will
manually add the libraries it has detected that language's compiler as
linking implicitly.  When it does this, it'll pass -Bstatic and
-Bdynamic options based on the vibes it gets from each such detected
library.  This in itself isn't a problem, because the compiler
toolchain, or our wrapper, or something, seems to be smart enough to
ignore -Bdynamic for those libraries.  But it does create a problem if
the compiler adds extra libraries to the linker command line after
that final -Bdynamic, because those will be linked dynamically.  Since
our compiler is static by default, CMake should reset to -Bstatic
after it's done manually specifying libraries, but CMake didn't
actually know that our compiler is static by default.  The fix for
that is to tell it, like so.

Until recently, this problem was difficult to notice, because it would
result binaries that worked, but that were dynamically linked.  Since
e08ce498f0 ("cc-wrapper: Account for NIX_LDFLAGS and NIX_CFLAGS_LINK
in linkType"), though, -Wl,-dynamic-linker is no longer mistakenly
passed for executables that are supposed to be static, so they end up
created with a /lib interpreter path, and so don't run at all on
NixOS.

This fixes pkgsStatic.graphite2.
This commit is contained in:
Alyssa Ross 2023-11-23 12:28:49 +01:00 committed by Adam Joseph
parent 4552f3aa25
commit 0d44b5b773

View file

@ -427,6 +427,8 @@ else let
"-DCMAKE_HOST_SYSTEM_VERSION=${stdenv.buildPlatform.uname.release}"
] ++ optionals (stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
"-DCMAKE_CROSSCOMPILING_EMULATOR=env"
] ++ lib.optionals stdenv.hostPlatform.isStatic [
"-DCMAKE_LINK_SEARCH_START_STATIC=ON"
]);
mesonFlags =