1. when db.h provides ndbm compat layer, include db.h not ndbm.h.
Otherwise, compilation fails due to incompatible type declarations
between libSystem and db includes.
2. tell the build system that db_185.h is present.
Otherwise, the code includes db.h as if it's v1 header. (It's not.)
3. link some tests with -lresolv where needed.
All three patches are posted upstream.
Closes: #347616
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
krb5 and libkrb5 are two separate derivations that can easily end up
in the same closure. They both provide the same shared libraries and
some packages end up getting both copies. Since both copies come from
the same source, packages often get lucky in this situation and just
use whichever library is found first. Sometimes packages are less
fortunate and end up trying to load both. This has gone largely
unnoticed in Nixpkgs, likely because Kerberos is not widely used
outside of enterprise deployments.
This situation seems to have arisen out of a need to break a cycle
in `fetchurl -> curl -> krb5 -> fetchurl`. The libkrb5 build was able to
avoid depending on bison and libedit, making it easier to break the
cycle.
However, we can break the cycle without resorting to two variants of
krb5. Libedit can be removed with configure flags and byacc can be used
instead of bison, allowing a much smaller build closure that can easily
be resolved when breaking the cycle.
This change also adds a "lib" output to krb5 so that packages depending
on krb5 can still benefit from a smaller runtime closure if they only
need the shared libraries.
A future change will include a tree-wide refactor to switch uses of
libkrb5 to krb5.
- Introduce more possible options by using the krb format generator.
- Enforce package choice is using a correct package.
- Use meta attribute to decide implementation, allows for overriding the
package.
- Make necessary changes to the format, to allow for multiple ACL files in
heimdal.
- Add systemd target and slice for both implementations.
- Move state to `/var/lib`
- Add documentation
Prior to August 2023, any config.guess generated by autoconf will
include a hardcoded /usr/bin/uname invocation for FreeBSD on any
architecture other than arm. This clearly doesn't work under nix.
We must then update or otherwise patch each old config.guess.
- Make inputs more diff friendly
- Add flags for enabling certain libraries
- Disable LDAP support as HDB module by default
- Add support for CJSON
- Flatten contents of `$out/libexec`, which earlier had an
`heimdal/heimdal` directory
- Use SRI hash
- Enable package tests
- Add `passthru.tests.nixos`
- Add `meta.homepage` and `meta.changelog`
Co-authored-by: Felix Albrigtsen <felix@albrigtsen.it>
Passing `-l$NIX_BUILD_CORES` improperly limits the overall system load.
For a build machine which is configured to run `$B` builds where each
build gets `total cores / B` cores (`$C`), passing `-l $C` to make will
improperly limit the load to `$C` instead of `$B * $C`.
This effect becomes quite pronounced on machines with 80 cores, with
40 simultaneous builds and a cores limit of 2. On a machine with this
configuration, Nix will run 40 builds and make will limit the overall
system load to approximately 2. A build machine with this many cores
can happily run with a load approaching 80.
A non-solution is to oversubscribe the machine, by picking a larger
`$C`. However, there is no way to divide the number of cores in a way
which fairly subdivides the available cores when `$B` is greater than
1.
There has been exploration of passing a jobserver in to the sandbox,
or sharing a jobserver between all the builds. This is one option, but
relatively complicated and only supports make. Lots of other software
uses its own implementation of `-j` and doesn't support either `-l` or
the Make jobserver.
For the case of an interactive user machine, the user should limit
overall system load using `$B`, `$C`, and optionally systemd's
cpu/network/io limiting features.
Making this change should significantly improve the utilization of our
build farm, and improve the throughput of Hydra.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
