Arguably, this is a bug in Nix's structuredAttrs: without
structuredAttrs, exportReferencesGraph with an empty path set would
still result in information being provided. With structuredAttrs, no
info is provided for an empty path set.
Nevertheless, we need to be able to build even if Nix has the bug, so
work around it by checking for an empty path set and handling it
explicitly.
Darwin does not actually require `*.dylib` extension, and some ports of
unix software may still simply compile and install these as `*.so` files.
Include `*.so` in the find in this case.
Co-authored-by: Artturi <Artturin@artturin.com>
Co-authored-by: toonn <toonn@toonn.io>
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustPackage.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustCrate.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Before this commit, cc-wrapper/default.nix was using
`isGccArchSupported` to validate `-mtune=` values. This has two
problems:
- On x86, `-mtune=` can take the same values as `-march`, plus two
additional values `generic` and `intel` which are not valid for
`-march`.
- On ARM, `-mtune=` does not take the same values as `-march=`;
instead it takes the same values as `-mcpu`.
This commit fixes these two problems by adding a new
`isGccTuneSupported` function. For `isx86` this returns `true` for
the two special values and otherwise defers to `isGccArchSupported`.
This commit also adds support for `-mtune=` on Aarch64.
Unfortunately on Aarch64, Clang does not accept as wide a variety of
`-mtune=` values as Gcc does. In particular, Clang does not tune
for big.LITTLE mixed-model chips like the very popular RK3399, which
is targeted using `-march=cortex-a72.cortex-a53` in gcc.
To address this problem, this commit also adds a function
`findBestTuneApproximation` which can be used to map
clang-unsupported tunings like `cortex-a72.cortex-a53` to
less-precise tunings like `cortex-a53`.
The work which led to this commit arose because we now have
packages, like `crosvm`, which use *both* `clang` *and* `gcc`.
Previously I had been using `overrideAttrs` to set
`NIX_CFLAGS_COMPILE` on a package-by-package basis based on which
compiler that package used. Since we now have packages which use
*both* compilers, this strategy no longer works.
I briefly considered splitting `NIX_CFLAGS_COMPILE` into
`NIX_CFLAGS_COMPILE_GCC` and `NIX_CFLAGS_COMPILE_CLANG`, but since
`NIX_CFLAGS_COMPILE` is sort of a hack to begin with I figured that
adding the logic to `cc-wrapper` would be preferable.
Cargo will never need to link for the target platform — that'd be for
the package being built to do at runtime. Cargo should know about the
build and host linkers.
This fixes e.g. pkgsCross.musl64.fd from x86_64-linux.
Fixes: 67a4f828b4 ("rust: hooks: fix cross compilation")
This upgrade unfortunately removes MIPS support, as it has been
dropped to Tier 3[1] and so bootstrap tarballs are no longer provided.
It looks like it was dropped due to multiple codegen bugs, and lack of
maintenance, so bringing it back would probably involve engaging with
Rust/LLVM upstream on those.
[1]: https://github.com/rust-lang/compiler-team/issues/648
So in php we have a bootstrapping composer (that lives in
composer-phar.nix) that downloads the binary distribution of composer
to be able to bootstrap and build a composer built from source.
However, it's desirable to keep composer updated at all time, and this
includes the phar one that isn't used by users directly. So this makes
sure we don't "forget" about the phar one since it now borrows the
version from the source version. However, then it also made sense to
move the hash for the phar to the same file as the source
composer. Then we can control the full upgrade life cycle of both the
phar and source versions of composer from the same file.
It's useful to have access to these attributes from packages built with
buildFHSEnvBubblewrap, and it reduces the difference between FHS and
non-FHS packages.
'name' is already handled by runCommandLocal.
This fixes a regression introduced in https://github.com/NixOS/nixpkgs/pull/256628
which broke fetching with private = true through a netrc file.
Tested locally with a really special github enterprise.
The commit 6f2b3ba027 introduced a
`mktemp` invokation that uses the `--tmpdir` flag, which is not
available on MacOS.
This changes the invokation to a portable one based on the following
StackOverflow answer https://stackoverflow.com/a/31397073/841562 .
Derivations affected by this patch set `__structuredAttrs = true;` and
provide their own `builder`, i.e. it's necessary to `source .attrs.sh`.
Rather than adding even more `if`-`source` monstrums, I decided to
modify all of those derivations to use `buildCommand` or `runCommand`,
without `builder` being set.
Then, `$stdenv/setup` is sourced already and as a result it's safe to
assume that `NIX_ATTRS_JSON_FILE`/`NIX_ATTRS_SH_FILE` point to a usable
location both in a build and a shell session.
When specifying the `builder` attribute in `stdenv.mkDerivation`, this
will be effectively transformed into
builtins.derivation {
builder = stdenv.shell;
args = [ "-e" builder ];
}
This also means that `default-builder.sh` is never sourced and as a
result it's not guaranteed that `$NIX_ATTRS_SH_FILE` is set to a correct
location[1].
Also, we need to source `.attrs.sh` to source `$stdenv`. So, the
following is done now:
* If `$NIX_ATTRS_SH_FILE` points to a correct location, then use it.
Directly using `.attrs.sh` is problematic for `nix-shell(1)` usage
(see previous commit for more context), so prefer the environment
variable if possible.
* Otherwise, if `.attrs.sh` exists, then use it. See [1] for when this
can happen.
* If neither applies, it can be assumed that `__structuredAttrs` is
turned off and thus nothing needs to be done.
[1] It's possible that it doesn't exist at all - in case of Nix 2.3 or
it can point to a wrong location on older Nix versions with a bug in
`__structuredAttrs`.
> If using a target spec JSON file, the <triple> value is the filename
> stem. For example --target foo/bar.json would match [target.bar].
- https://doc.rust-lang.org/cargo/reference/config.html#target
I've also exposed toRustTargetSpecShort as a public function, because
it's useful to be able to know what the target subdirectory will be.
This function helps building an OCaml package that builds with topkg.
There are currently many such packages in nixpkgs and this function
would greatly simplify adding more.
This is heavily inspired by `ocamlPackages.buildDunePackage`.
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
Currently there is a state of severe confusion in
pkgs/build-support/rust/hooks/ regarding host vs target; right now
there is only "host" defined, but whether it means "host" or
"target" seems to fluctuate.
This commit corrects that, ensuring that all variables come in all
three flavors (build, host, target) and are used consistently with
the nixpkgs convention.
This also fixes the cross-compilation of packages which use
`maturinBuildHook` -- hooks go in `nativeBuildInputs` and are
phase-shifted backwards by one platform, so they need to be careful
about distinguishing between build and host.
Closes#247441
`buildFHSEnvBubblewrap { pname = ...; }` currently results in eval error
because args.name doesn't exist then. Fix it by only using args.name if
it exists.
It's useful to be able to introspect all packages which are available
in the fhsenv. I've renamed basePkgs and baseMultiPkgs to be
consistent with the naming scheme used for the bits that were
previously public — names ending in "Pkgs" are for functions, and
names ending in "Paths" are the results of those functions.
nix-prefetch-git is either run as part of a build, usually sandboxed,
or outside a build, unsandboxed, to prefetch something that will later
be used in a build. It's important that the latter use produces
hashes that can be reproduced by the former.
One way that they can differ is if the user's git config does
something that changes the result of git clone. I ran into this,
because my global git config automatically enables git-lfs, whereas
nix-prefetch-git otherwise only uses git-lfs if specifically
requested. This led to very confusing hash mismatches.
Removed workaround from llvm 16.
Fixes including cxxabi.h on llvm >=15 libcxxStdenv.
```c
int main() {}
```
```
/nix/store/qwnvng0cbyx0bijm654jpmpl0516hfhx-libcxxabi-15.0.7-dev/include/cxxabi.h:20:10: fatal error: '__cxxabi_config.h' file not found
```
Before llvm 15 this used to work because `libcxx` copied the headers
from `cxxabi` to it's own `include`, which was then picked up by the
line above this one
Alternative fix would be to copy all files from `${cxxabi.dev}/include/c++/v1` to `${cxxabi.dev}/include` so the cc-wrapper setup hook would pick them up, but that would depend on in cxxabi being in buildInputs.
Signed-off-by: Amneesh Singh <natto@weirdnatto.in>
Hooks are essentially implemented as special shell packages that run on
their respective host platform. When they are used, they appear as
nativeBuildInputs (as they need to be executed as part of the build of a
package using them) so are taken from buildPackages relative to the
derivation using them.
Since the override in buildNpmPackage nullifies splicing, we take
npmHooks from buildPackages manually.
Fixes pkgsCross.ghcjs.buildPackages.emscripten and thus
pkgsCross.ghcjs.haskellPackages.ghc.
The implicit contract of buildFHSUserEnv was that it allows to run
software built for a typical GNU/Linux distribution (not NixOS) without
patching it (patchelf, autoPatchelfHook, etc.). Note that this does not
inherently imply running untrusted programs.
buildFHSUserEnv was implemented by using chroot and assembling a
standard-compliant FHS environment in the new root. As expected, this
did not provide any kind of isolation between the system and the
programs.
However, when it was later reimplemented using bubblewrap
(PR #225748), which *is* a security tool, several isolation features
involving detaches Linux namespaces were turned on by default.
This decision has introduced a number of breakages that are very
difficult to debug and trace back to this change.
For example: `unshareIPC` breaks software audio mixing in programs using
ALSA (dmix) and `unsharePID` breaks gdb,
Since:
1. the security features were enable without any clear threat model;
2. `buildFHSEnvBubblewrap` is supposed to be a drop-in replacement of
`buildFHSEnvChrootenv` (see the release notes for NixOS 23.05);
3. the change is breaking in several common cases (security does not
come for free);
4. the contract was not changed, or at least communicated in a clear
way to the users;
all security features should be turned off by default.
P.S. It would be useful to create a variant of buildFHSEnv that does
provide some isolation. This could unshare some namespaces and mount
only limited parts of the filesystem.
Note that buildFHSEnv mounts every directory in / under the new root, so
again, very little is gained by unsharing alone.
