Deprecate singularity-tools.mkLayer and singularity-tools.shellScript,
for they are no longer related to image building.
Use writers.writeBash instead of singularity-tools.shellScript.
Allow users to pass arguments to `buildDotnetModule` in the form:
```nix
buildDotnetModule (finalAttrs: {
# Args
})
```
Exposing the behaviour of the underlying `mkDerivation` and allowing
packages to be defined in a recursive way that works correctly even when
the package is overridden, e.g. using `overrideAttrs`.
Added some simple test cases that piggyback on the existing
`structured-attrs` test.
*compressDrv* compresses files in a given derivation.
*compressDrvWeb* compresses a derivation for a loosely-defined
pre-compressed "web server" usage.
This intends to replace the `passthru.data-compressed` derivations that
have accumulated in nixpkgs with something more reusable.
The current error message is hard to debug because the error is in the
nix store:
> Error: failed to parse JSON in
"/build/.attr-1s42g1c76fxb77skzq0b4wdhcrg8jmzb54czmxvh1qm7psgsbcni"
>
> Caused by:
> missing field `source` at line 1 column 102
>
> Location:
> src/main.rs:329:10
* streamLayeredImage: self-document the script
'podman load' doesn't let me override the name/tag from the image.
This name and tag is dynamic and in a CI environment so I would like to
be able to adjust the tag dynamically.
Since the image is streamed by stream_layered_image.py, there is no need
to stick with the nix-hardcoded image name/tag: the python script can
accept another name
I've added argparse to expose the feature. It has the added benefit of
adding `--help` support to the script, which makes its usage
self-explanatory.
* blackified file
'command -v builtin' returns 'builtin', which doesn't suit us since
we're looking for program in the given PATH. This could give us shebangs
like this:
#!builtin
which is surprising.
Switch to 'type -P command' which always returns a path, even if command
is both a builtin and an executable (for example 'test'), or fail is
'command' is just a builtin.
The docker-tools test, where this originates, was not run on aarch64-linux, but this is an artifact of its age more so than anything else.
Co-authored-by: Ivan Trubach <mr.trubach@icloud.com>
This removes redundant inline docs, because
- users should consult the better docs in the manual,
- contributors should add to the manual, not the inline comments
Before this commit, `pkgs/build-support/cc-wrapper/add-flags.sh`
was using `-B@out@/bin` instead of `-B@bintools@/bin`
to force `cc` to use `ld-wrapper.sh` when calling `ld`.
That was confusing `cc` when asked to print
the location of a library precisely named `c++`
because `-B` prefixes are also used by `cc` to find libraries,
see https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#index-B
Indeed, instead of having `cc --print-file-name c++`
failing to found a `c++` library and just returning the given `c++` string
to let a linker resolve it thereafter,
it was finding that `@out@/bin/c++` executable,
mistaking it for a library and returning its absolute path,
forcing the linker to load an executable as a library.
Before this commit:
```console
$ nix run -f . stdenv.cc -- --print-file-name c++
/nix/store/9bv7dcvmfcjnmg5mnqwqlq2wxfn8d7yi-gcc-wrapper-13.2.0/bin/c++
```
After this commit:
```console
$ nix run -f . stdenv.cc -- --print-file-name c++
c++
```
Fixes https://gitlab.haskell.org/ghc/ghc/-/issues/23138#note_567034
where this behavior was breaking GHC on Darwin.
[Confirmed by @414owen](https://github.com/NixOS/nixpkgs/pull/317224#issuecomment-2171276177):
> This fixed all our haskell builds on Arm64 darwin, which were trying
> to link in clang++...
When the hash of an url being fetched does not match the expected value, this
commit will cause fetch-yarn-deps to include the url in the error message to
assist debugging.
When a dependency references a github *release* URL, that dependency must be
fetched using https rather than git, since github does not require that
release tarballs have any relationship whatsoever to the git history.
This commit causes them to be fetched using https, not git.
A test case (which fails prior to this commit, and passes afterwards) is included.
There's no point generating debug info if the compiler immediately
strips it before we get a chance to do anything with it.
This is especially important since Cargo 1.77, which asks rustc to
strip by default.
Updates tests for testers.testEqualContents with diffoscope and fixes
some bugs in tests (e.g. fileDiff always succeed because subshell does
not inherit errexit option).
Before this change, testers.testEqualContents implementation had several
bugs (e.g. executables at different paths were not considered equal). So
we switch to diffoscope that that is designed to handle exactly these
kinds of comparisons and gives more insights into the differences in the
output.
modules-closure.sh seems to consider everything under
/lib/firmware to be a kernel module,
this change adds a special handling of `edid` directory,
which does not contain kernel modules
fixes#279739
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will
update ad hoc signatures after they perform their modifications.
The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful.
In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature.
It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one.
Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin.
Fixes https://github.com/NixOS/nixpkgs/issues/208951.
Darwin and its bootstrap tools both use LLVM 16, which is sufficient for
arm64e support in LLVM. Thsi change removes an unnecessary LLVM 13 build
from the stdenv bootstrap.
This changes ld-wrapper to use a temporary file for the response file
passed to ld instead of using process substitution.
ld64 does not handle long command-lines when reading from the response
file, which defeats the point of using a response file to handle long
command-lines. cctools-port was patched to work around this, but nixpkgs
is now using Apple’s source release directly instead of the port.
Since it’s preferable not to patch Apple’s release heavily (to reduce
the difficulty of updating to new versions and to match upstream’s
behavior), use the approach that was adopted in cc-wrapper to work
around issues with response files in newer versions of clang.
Related PRs (cctools-port):
- https://github.com/NixOS/nixpkgs/pull/213831
- https://github.com/tpoechtrager/cctools-port/pull/132
Related PRs (cc-wrapper):
- https://github.com/NixOS/nixpkgs/pull/245282
- https://github.com/NixOS/nixpkgs/pull/258608
This makes the minimal change to put the script in a new file.
It does not fix the resulting ShellCheck warnings (which would
have been present in the previous version; I've just exposed
them).
As a consequence of restrictions imposed by RFC 140 - Simple Package Paths [1]
-, files related to a package should be confined on the package directory.
Certainly this restriction does not apply to packages outside by-name hierarchy.
Nonetheless, this is an interesting organization heuristics: things that affect
Emacs should be confined inside Emacs directory. Besides a future migration, the
"debuggability" of a framework is way more enhanced when we know how to find all
its files.
A similar task was done before, when RFC 140 was not a thging yet - namely, the
migration of emacs-modes to elisp-packages [2].
[1] https://github.com/NixOS/rfcs/pull/140
[2] https://github.com/NixOS/nixpkgs/pull/123859
This is executed curing the build, and usually quite helpful in telling
you how the build failed, if it failed.
For example, when linking against system libraries, it shows which
system lib could not be discovered, the pkg-config path used etc.
Not showing it simply removes all this, and trying to parse out the
"important" bits and only show these is probably also brittle.
The output generally isn't that spammy normally, so let's just `tee` it.
ccName points to the pname of the unwrapped cc minus the targetPrefix,
thus is always incorrect for cross compilers whose wrappers are prefixed
with the target platform name.
This reverts commit 9f4b1064c6.
It caused problems: https://github.com/NixOS/nixpkgs/pull/318872#issuecomment-2196168990
FODs are not allowed to have references, but writeText is often used to create a file with references.
Leading to this error:
error: fixed output derivation 'packages.json' is not allowed to refer to other store paths.
Added a cross compilation test for wasm32-unknown-unknown. This also
required using crate.metadata instead of using the regex to get rid of
the hash in the library filename. It also required adding a mkCrate
argument to assertOutputs so we can override the buildRustCrate used.
With this change you will finally be able to use
buildRustCrate/crate2nix to build your wasm32-unknown-unknown
rust projects.
Simply import nixpkgs like so:
```
lib = <nixpkgs/lib>;
pkgsForWasm32 = import <nixpkgs> {
crossSystem = lib.examples.wasm32-unknown-none;
}
```
or use pkgsCross directly with
```
pkgsCross.wasm32-unknown-none.callPackage ./. { };
```
Allow the macOS GLUT framework to be used automatically in many
cases. Packages that specifically search for freeglut or require its
additional APIs should still explicitly depend on it.
Deliberately skip the Haskell package set, which is mostly
automatically generated, and mupdf, which has its own fork of freeglut.
* ocamlPackages.wtf8: use minimalOCamlVersion
* ocamlPackages.ppx_yojson_conv: minimalOCamlVersion
* ocamlPackages.postgresql: use minimalOCamlVersion
* ocamlPackages.opti: use minimalOCamlVersion
* ocamlPackages.opam-repository: use minimalOCamlVersion
* ocamlPackages.opam-format: use minimalOCamlVersion
* ocamlPackages.lwt-dllist: use minimalOCamlVersion
* ocamlPackages.lacaml: use minimalOCamlVersion
* ocamlPackages.gnuplot: use minimalOCamlVersion
* ocamlPackages.fix: use minimalOCamlVersion
* ocamlPackages.eigen: use minimalOCamlVersion
* ocamlPackages.earley: use minimalOCamlVersion
* ocamlPackages.directories: use minimalOCamlVersion
* ocamlPackages.cpuid: use minimalOCamlVersion
* build-support/ocaml: deprecate minimumOCamlVersion
* build-support/ocaml: deprecate minimumOCamlVersion
---------
Co-authored-by: Vincent Laporte <Vincent.Laporte@gmail.com>
In order to allow for the new `cargo::` prefix for build script outputs
we have to adjust the configure-crate bash scripts in buildRustCrate to
properly parse the new additional syntax.
These changes don't affect existing build scripts configured with the
old `cargo:` prefix.
For more information, see https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script
GStreamer searches for plugins relative to its binary's location.
However, since bd97973ce0, it uses its *real* binary location, breaking the FHS.
Fixes#311004 (tested on Heroic and Lutris too).
When cross compiling proc macros, the proc macro needs to be built for the
build platform's architecture.
Without this change cross compiling from Darwin to Linux would simply
fail because it tries to link to a library with a file extension that
doesn't exist on the builder's platform.
Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d9 (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
We already did this for -march in 12b0e8ac74 ("clang: don't set
-march for overridden target"), but it should have been done for all
machine flags, for the same reason.
Example bug this fixes:
nix-shell -E '
with import ./. {
crossSystem = {
system = "powerpc64le-linux";
gcc.cpu = "power10";
};
};
clangStdenv.mkDerivation { name = "test"; }
' --run '$CC -target wasm32-unknown-unknown -c /dev/null'
Which previously failed with:
clang: error: unsupported option '-mcpu=' for target 'wasm32-unknown-unknown'
This would cause any drv to be rebuilt when any part of the default.nix changes.
What we actually care about is the two JS files though, so simply reference them
directly.
Co-authored-by: Infinidoge <infinidoge@inx.moe>
