fixes e.g.:
pkgsMusl.libfsm
pkgsMusl.libiscsi
pkgsMusl.nsjail
pkgsMusl.pv
match strings have whitespace on either side, which wasn't
matching leading/trailing arguments previously
fixes:
pkgsMusl.bulletml
pkgsMusl.proot
pkgsMusl.python3
Debian explains this issue well in the dpkg-buildflags manpage:
-fPIE
Can be linked into any program, but not a shared library (recommended).
-fPIC
Can be linked into any program and shared library.
On projects that build both programs and shared libraries you might need to
make sure that when building the shared libraries -fPIC is always passed last
(so that it overrides any previous -PIE) to compilation flags such as CFLAGS.
(from https://manpages.debian.org/bullseye/dpkg-dev/dpkg-buildflags.1.en.html#hardening)
In restricted mode (and therefore with flakes) `builtins.readFile` may not be the result of `builtins.toFile`,
making it impossible to use a generated lockFile (with or without IFD),
and thereby causing evaluation to fail if `system != builtins.currentSystem` on Hydra
so the jobs are not delegated to eligible build machines that support that system.
This is done in a way that avoids rebuilds.
autoPatchelfHook actually doesn't depend on stdenv and only needs
bintools (with its wrapper). This change uses $NIX_BINTOOLS instead of
$NIX_CC and makes the dependency on bintools explicit.
Fully enabling crossSystem support for autoPatchelfHook came with some
perhaps unintended consequences of being a bit more aggressive about
patching ELF files from architectures/ABIs that differ from the target
(previously, those files would be ignored because ldd usually couldn't
handle them).
This change adds architecture and rough OS ABI detection to the script
so that it doesn't try to blindly replace the interpreter of files that
can't possibly use that interpreter, and also makes sure it doesn't
accidentally use libraries of other architectures/ABIs.
The current name is misleading: it doesn't contain cli arguments,
but several constants and utility functions related to qemu.
This commit also removes the use of `with import ...` for clarity.
`--enable-deterministic-archives` is a GNU specific strip flag and
causes other strip implementations (for example LLVM's, see #138013)
to fail. Since strip failures are ignored, this means that stripping
doesn't work at all in certain situation (causing unnecessary
dependencies etc.).
To fix this, no longer pass `--enable-deterministic-archives`
unconditionally, but instead add it in a GNU binutils specific strip
wrapper only.
`commonStripFlags` was only used for this flag, so we can remove
it altogether.
Future work could be to make a generic strip wrapper, with support for
nix-support/strip-flags-{before,after} and NIX_STRIP_FLAGS_{BEFORE,AFTER}.
This possibly overkill and unnecessary though -- also with the
additional challenge of incorporating the darwin strip wrapper somehow.
In #84415, autoPatchelfHook was taught to use the correct path to the
readelf binary when a crossSystem is specified. Unfortunately, the
remainder of the functionality in the script depended on ldd, which only
reads ELF files of its own architecture. It has the further unfortunate
quality of not reporting any useful error, but rather that the file is
not a dynamic executable.
This change uses patchelf to directly analyze the DT_NEEDED tags in the
target files instead, which correctly works across architectures. It
also updates the use of objdump to be prefix-aware $OBJDUMP (which would
have been required in the PR mentioned above, but we never made it that
far into the script execution).
I currently do not have much time to work on nixpkgs. Remove
myself as a maintainer from a bunch of packages to avoid that
people are waiting on me for a review.
Conflicts:
pkgs/development/compilers/ghc/8.10.7.nix
pkgs/development/compilers/ghc/8.8.4.nix
I've removed the isWindows check from useLdGold in ghc, since that should
be covered by the new hasGold check.
I somehow accidentally left out the lib.flatten from mergeInputs. Without it, subtractLists won't ever remove anything from the inputs since the inputs will be a list of lists.
The motivation for inputsFrom is to create a shell environment that is suitable for development of the packages listed in inputsFrom. This commit filters out any dependencies from one package in inputsFrom to another when computing the shell environment's inputs. This supports the use case where several closely related packages (perhaps even built from the same source tree) are being mutually developed. It is assumed that the user will configure their environment to resolve dependencies between these mutually developed packages.
This function is fundamentally broken.
Not even the ncurses example will compile.
The interface needs to be rethought for it to work (i.e. don't
unconditionally include all pc files, set include path and ld path and
rpath).
Since it is unlikely that in the current this has any user, just drop it for now.
dyld: lazy symbol binding failed: Symbol not found: _dsyevd_
Referenced from: /nix/store/lr8grz1knmh6vc7j830gni0ka68qf1lk-xfitter-2.0.1/bin/xfitter
Expected in: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
Fixes https://github.com/dhall-lang/dhall-haskell/issues/2267
`pkgs.dhallToNix` currently fails when a Dhall package is
interpolated into the input source code, like this:
```nix
let
pkgs = import <nixpkgs> { };
f = { buildDhallPackage }: buildDhallPackage {
name = "not";
code = "λ(x : Bool) → x == False";
source = true;
};
not = pkgs.dhallPackages.callPackage f {};
in
pkgs.dhallToNix "${not}/source.dhall True"
```
This is because `dhallToNix` was using `builtins.toFile`, which
does not permit inputs with interpolated derivations. However,
`pkgs.writeText` does not have this limitation, so we can switch
to using that instead.
