I am building a cmake project and don’t know why this error occurs and how to solve it
(import <nixpkgs> {}).callPackage (
{
fetchFromGitHub,
pkg-config,
stdenv,
lib,
cmake,
cacert,
python3,
ninja,
ccache,
nodejs_20,
}:
stdenv.mkDerivation (finalAttrs: rec {
pname = "MaaFramework";
version = "2.2.2";
src = fetchFromGitHub {
owner = "MaaXYZ";
repo = finalAttrs.pname;
rev = "ab0dcffc02650d722fed59eb5e6d994e3240c010";
fetchSubmodules = true;
sha256 = "sha256-zfjcK18u2qBD6eXf6wUTjBbEP35HT7jX5upl1OrUxaI=";
};
nativeBuildInputs = [
pkg-config
cmake
python3
];
# makeFlags = [
# "DMAADEPS_TRIPLET=maa-x64-linux"
# "DMAA_HASH_VERSION=2.2.2"
# "DBUILD_NODEJS_BINDING=ON"
# "PREFIX=${placeholder "out"}"
# ];
NIX_SSL_CERT_FILE = "${cacert}/etc/ssl/certs/ca-bundle.crt";
preConfigure = ''
python tools/maadeps-download.py x64-linux
'';
dontStrip = true;
outputHashMode = "recursive";
outputHashAlgo = "sha256";
outputHash = lib.fakeHash;
})
) {}
Atemu
November 29, 2024, 3:37pm
2
Well, why did you make it a fixed-output-derivation?
Because the python script downloads the binary file
I didn’t do that, why do you say that?
This makes it a fixed-output derivation. Remove these lines.
And if you need to access the network, ensure you do that within a fixed-output derivation that doesn’t download content with such path references (ideally you should use your own fetchers rather than using a python script that can execute arbitrary code with network access)
like deine a vairable to store which use fetchurl to get?
You may be interested in this nix issue I made about making this easier to debug:
opened 12:58AM - 11 Oct 24 UTC
feature
**Is your feature request related to a problem? Please describe.**
I ran into… the quoted error message recently and found it pretty difficult to track down what the path references actually were. There's some evidence of other people having trouble with this too:
- https://discourse.nixos.org/t/illegal-path-references-in-fixed-output-derivation/44360
- https://phip1611.de/blog/fixing-illegal-path-references-in-fixed-output-derivation-in-nix/
I was particularly flummoxed by how when I used `nix-build --keep-failed`, the directory I got didn't contain any store path references; I later figured out it kept the build directory, not `$out`, and I was writing the path references directly to the latter. It was frustrating that `nix` wouldn't tell me what paths I was referencing, or where they were referenced.
**Describe the solution you'd like**
I just went ahead and wrote https://github.com/NixOS/nix/commit/86540620290e2dee56adc0656c48a232251f8e9e which at least gives an example path, and changes the wording so that it's more clear what's illegal about the path references. One disadvantage of changing the wording is that you'd no longer be able to google the error message to get those helpful references above, but perhaps we could leave a comment on each mentioning the new message :)
I was going to open a PR instead of an issue, especially since the proposed change is so small, but I think there's a pretty strong chance that people more familiar with nix internals might have ideas about how to do something more ambitious that would be much more helpful, so it seemed sensible to make the issue first. I basically only read the part of the nix code that generated this error message, and my C++ is very rusty, so there's lots of ways my approach might not be right. But if people do like it, even if only as a first step, happy to open a PR with that.
**Describe alternatives you've considered**
One alternative is to give an example path but not change the error wording, to retain googleability. I think googleability is not important enough to go this way, but happy to hear other opinions.
Another alternative I considered was to dump *all* the bad references, perhaps gated behind a verbosity control or something. I currently lack the knowledge to implement this, but I could probably work it out if people think it's significantly better.
Even better would be anything that helps the user know exactly which file has the bad reference in it, which would presumably mean checking for the error at a different point in the code. (Again, I lack the knowledge to do this, but I could give it a go perhaps.)
For either of the latter two ideas, we could perhaps merge my easy change first, before I embark on something more difficult :)
In either case
**Additional context**
Here's an example output from my commit:
```
error: fixed-output derivations must not reference store paths: '/nix/store/c3w5x4sgszgl9f737l4012814aw72kwy-friendica-2024.08.drv' references 3 distinct paths, e.g. '/nix/store/516kai7nl5dxr792c0nzq0jp8m4zvxpi-bash-5.2p32'
```
(aside: if there is only one path it will say "1 distinct paths" and then give the only path as an example, which is somewhat silly, but when I tried to do something cleverer it highlighted the "s, e.g. " in purple, I guess because it does that with all printf-formatted components)
**Priorities**
Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
and some of the stuff I linked from there. The most common causes of this error that I’m aware of are:
Cloning a git repo, which creates a bunch of sample hook scripts whose hashbangs directly reference your currently-installed bash (which is a nix store path, which is the disallowed thing). The main fix here is to wipe out any .git
directories entirely if you don’t need them. (Note that fetchFromGitHub
doesn’t clone the repo with git, it just downloads the requested revision as a tarball, so you don’t need to do anything there.)
The patch-shebangs step of the fixup phase in a normal derivation, which again replaces things like #!/bin/bash
with store paths to your current bash version. The usual fix here is to set dontPatchShebangs = true;
in your derivation, or even dontFixup = true;
if you don’t need anything else from the fixup phase. I guess this might mean that your shebang lines in your scripts don’t work properly. Maybe you can manually patch them, or you can do something like have a fixed-output derivation that just downloads the stuff, and then another non-fixed-output derivation that does everything else, including patching the shebangs as appropriate.
thx,i works by this
{
fetchurl,
fetchFromGitHub,
pkg-config,
stdenv,
lib,
cmake,
python3,
}: let
maadepsdev = fetchurl {
url = "https://github.com/MaaXYZ/MaaDeps/releases/download/v2.7.1/MaaDeps-x64-linux-devel.tar.xz";
hash = "sha256-gneNVcaAmiXavMUgRBUnTajkgjQeOMnbQ9jDoghx+lY=";
};
maadepsruntime = fetchurl {
url = "https://github.com/MaaXYZ/MaaDeps/releases/download/v2.7.1/MaaDeps-x64-linux-runtime.tar.xz";
hash = "sha256-iz51FZKqPY8yYA7cilfqIH8W2Oyz33tH5qEOHNB0ny4=";
};
in
stdenv.mkDerivation rec {
pname = "MaaFramework";
version = "2.2.2";
src = fetchFromGitHub {
owner = "MaaXYZ";
repo = pname;
rev = "ab0dcffc02650d722fed59eb5e6d994e3240c010";
fetchSubmodules = true;
sha256 = "sha256-zfjcK18u2qBD6eXf6wUTjBbEP35HT7jX5upl1OrUxaI=";
};
nativeBuildInputs = [
pkg-config
cmake
python3
];
# makeFlags = [
# "DMAADEPS_TRIPLET=maa-x64-linux"
# "DMAA_HASH_VERSION=2.2.2"
# "DBUILD_NODEJS_BINDING=ON"
# "PREFIX=${placeholder "out"}"
# ];
preConfigure = ''
mkdir -p 3rdparty/MaaDeps/tarball
tar xf ${maadepsdev} -C 3rdparty/MaaDeps/
tar xf ${maadepsruntime} -C 3rdparty/MaaDeps/
'';
}
1 Like