Update to the new release of core lightning. The `--disable-developer`
flag got removed on core lightning. Developer builds are now always
enabled and can be toggeled at runtime by starting `lightningd` with the
option `--developer`.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
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.
Replace stringy license with a list of all used licenses.
The original meta.license said that the license was BSD-style but this information has been outdated for a long time.
The license was changed in 2008: bc108df382 (diff-7bb54d15ef4c4e0f20bb24add68a12fccced9925b304eaa696023143d278ea26).
The current license is clearly the zlib license and below that some notes about the licenses of `datasrc` (and `data`, which has not existed in the tree for many years), the fonts in `datasrc` and the libraries in `src/engine/external`.
See https://github.com/teeworlds/teeworlds/blob/master/license.txt for the current version of the license.
The meta.license string has been unchanged since the commit adding teeworlds in 2009: e71dbdbb83.
See issue #269788.
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+).
Darwin uses .dylib as the extension for dynamic libraries. Replace the
hardcoded extension with stdenv.hostPlatform.extensions.sharedLibrary
to fix magick support on darwin.
