I'm not sure why this was disabled, but when we later ran
"ninja install", it would be built anyway. Now that we run
"meson install", that's no longer implicit, so we have to have the
build step enabled.
Fixes: 10f35ff05d ("meson.setupHook: prefer meson commands over ninja")
NetBSD fts wasn't really designed to be used in this way, and it can
produce some strange errors — e.g. I sometimes see duplicate symbols
when musl and libnbcompat define the same symbol.
More packages used musl-fts directly than the fts package anyway,
which can now be changed to use the generic fts.
Unlike netbsd.fts, musl-fts doesn't have a setup hook, so we have to
tell packages that don't know about it to link against libfts. We
could decide to copy netbsd.fts's setup hook later if we want to.
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.
Using flat namespaces causes libstdc++ to link CoreFoundation, but
that fails after #265102. Since CoreFoundation is not actually needed,
disable flat namespaces to avoid linking it unnecessarily.
Disabling flat namespaces matches the behavior of newer versions of
libstdc++ (GCC 7+) when building for newer Darwin hosts (10.5+).
