The wrapper around `arm-none-eabi-gdb` was not passing through
the command line arguments. This would cause build systems that
attempted to determine the gdb version to hang.
Match the other wrapper by adding `"$@"`, and using `exec` to
call the unwrapped process.
Apply a patch from upstream `ghcjs/ghcjs/ghc-8.10` (not yet present in
the obsidiansystems fork we follow) to fix a build failure caused by an
emscripten update.
As the patch itself modifies patches that are used during configuration
(by `makePackages.sh`), it must be applied in the configured source derivation.
Darwin-specific builtins were present on x86-64-darwin, but not on
aarch64-darwin. This is the same issue as #186575, but while the fixes
were correctly applied to LLVM 15, we were still disabling the build of
builtins on aarch64-darwin. Likely just a confusion.
Apparently gcc has these `Makefile` targets:
- `""`
- `"bootstrap"`
- `"profiledbootstrap"`
... but no `"profiled"`. So if you want a profiled compiler, at the
moment, it should be bootstrapped.
If we ever decide to make the nixpkgs bootstrap use a profiled
compiler (which at the moment means nondeterminism) a Nix-driven
profile loop is certainly possible, but would take some work.
Closes#228597.
The 4aa95e3312 commit added support for
aarch64-darwin but also ignored platform flags if the build platform
is aarch64-darwin. This leads to confusing errors such as
`pkgsCross.raspberryPi` packages compiled with soft-float even though
the platform supports hard-float (and is built as such on other
platforms).
The correct way to ignore platform flags is to check `targetPlatform`,
not the build platform. This change fixes that.
While we're here, tigthen the special-case to cover only the problematic
flags: `-with-cpu` and `-with-arch`.
On MIPS, libsanitizer appears to have very detailed knowledge of the
Linux system call ABI manually encoded, by hand, into the library.
This encoding covers the o32 and 64 abis, but does not cover n32.
Adding support for n32 would be a major undertaking.
Without adding this encoding, builds of gcc will fail with errors
including (but not limited to) the following:
```
In file included from ../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:21:
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44: note: in definition of macro 'COMPILER_CHECK'
348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cpp:75:38: note: the comparison reduces to '(144 == 160)'
75 | COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:348:44: note: in definition of macro 'COMPILER_CHECK'
348 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
...
In file included from ../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:184:
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function '__sanitizer::uptr __sanitizer::internal_mmap(void*, uptr, int, int, int, u64)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24: error: '__NR_mmap2' was not declared in this scope
19 | # define SYSCALL(name) __NR_ ## name
| ^~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:198:27: note: in expansion of macro 'SYSCALL'
198 | return internal_syscall(SYSCALL(mmap2), addr, length, prot, flags, fd,
| ^~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function 'void __sanitizer::stat64_to_stat(stat64*, stat*)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:279:23: error: 'struct stat64' has no member named 'st_atim'; did you mean 'st_atime'?
279 | out->st_atime = in->st_atime;
| ^~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:280:23: error: 'struct stat64' has no member named 'st_mtim'; did you mean 'st_mtime'?
280 | out->st_mtime = in->st_mtime;
| ^~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:281:23: error: 'struct stat64' has no member named 'st_ctim'; did you mean 'st_ctime'?
281 | out->st_ctime = in->st_ctime;
| ^~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function '__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24: error: '__NR_stat64' was not declared in this scope
19 | # define SYSCALL(name) __NR_ ## name
| ^~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:353:30: note: in expansion of macro 'SYSCALL'
353 | int res = internal_syscall(SYSCALL(stat64), path, &buf64);
| ^~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function '__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24: error: '__NR_lstat64' was not declared in this scope
19 | # define SYSCALL(name) __NR_ ## name
| ^~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:378:30: note: in expansion of macro 'SYSCALL'
378 | int res = internal_syscall(SYSCALL(lstat64), path, &buf64);
| ^~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function '__sanitizer::uptr __sanitizer::internal_fstat(fd_t, void*)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24: error: '__NR_fstat64' was not declared in this scope
19 | # define SYSCALL(name) __NR_ ## name
| ^~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:397:30: note: in expansion of macro 'SYSCALL'
397 | int res = internal_syscall(SYSCALL(fstat64), fd, &buf64);
| ^~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp: At global scope:
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:303:13: warning: 'void __sanitizer::kernel_stat_to_stat(kernel_stat*, stat*)' defined but not used [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-function-Wunused-function8;;]
303 | static void kernel_stat_to_stat(struct kernel_stat *in, struct stat *out) {
| ^~~~~~~~~~~~~~~~~~~
mv -f .deps/sanitizer_mutex.Tpo .deps/sanitizer_mutex.Plo
make[4]: *** [Makefile:617: sanitizer_linux.lo] Error 1
mv -f .deps/sancov_flags.Tpo .deps/sancov_flags.Plo
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_posix.cpp: In function '__sanitizer::fd_t __sanitizer::OpenFile(const char*, FileAccessMode, error_t*)':
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_posix.cpp:162:27: warning: 'flags' may be used uninitialized [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized-Wmaybe-uninitialized8;;]
162 | fd_t res = internal_open(filename, flags, 0660);
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
../../../../gcc-12.2.0/libsanitizer/sanitizer_common/sanitizer_posix.cpp:156:7: note: 'flags' was declared here
156 | int flags;
| ^~~~~
```
The plugin now has a tagged version that is based on the date.
Previously, we had to use a random commit and manually choose the
relevant date. Now, we use the official tag as a version here
and to fetch from git.
While at it: fix the tests - somewhere over the course of the
lasts year, the tests stopped being run. Fixed now.
The `throwIf` expression in CUDNN was evaluated eagerly and essentially prevented the use of cudaPackages without a supported version of CUDNN (even when CUDNN was not requested).
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
Prior to this commit, builds of
`pkgsCross.aarch64-multiplatform.cargo` would fail due to being
unable to find `-lz` when compiling cargo's own `build.rs` for the
`buildPlatform`.
This environment variable uses the (very confusing) LLVM convention
of calling the buildPlatform "HOST".
Co-authored-by: figsoda <figsoda@pm.me>
clang_15 appears to not cross compile in the build!=(host==target)
case due to two problems, which this commit fixes:
- It trips -Wmaybe-uninitialized on recent gcc, but only in the
build!=host case (likely due to #ifdefs)
- Two more buildPlatform tools have been added:
clang-tidy-confusable-chars-gen and clang-pseudo-gen
Co-authored-by: Rahul Butani <rrbutani@users.noreply.github.com>
Our `rustc.nix` adds a `--target` flag for the host when doing a
host!=target build, but neglects to add a `--target` flag for the
buildPlatform when doing a build!=(host==target) build. This commit
corrects that.
Before rustc 1.68 omitting the --target flag for the buildPlatform
did not cause any problems. As of rustc 1.68, build!=host without a
--target for the build will fail like below (with hundreds more
"cannot find std::" errors.
```
$ nix build -f . -L pkgsCross.aarch64-multiplatform.rustc
...
Copying stage1 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Uplifting stage1 library (x86_64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
Copying stage2 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Building stage2 tool rust-analyzer-proc-macro-srv (aarch64-unknown-linux-gnu)
Compiling autocfg v1.1.0
Compiling libc v0.2.135
Compiling cfg-if v1.0.0
Compiling proc-macro2 v1.0.47
Compiling quote v1.0.21
Compiling unicode-ident v1.0.5
Compiling syn v1.0.102
Compiling once_cell v1.15.0
Compiling parking_lot_core v0.9.4
Compiling serde_derive v1.0.145
Compiling hashbrown v0.12.3
Compiling scopeguard v1.1.0
Compiling smallvec v1.10.0
Compiling log v0.4.17
Compiling serde v1.0.145
Compiling rustc-hash v1.1.0
error[E0463]: can't find crate for `std`
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:7:5
|
7 | println!("cargo:rerun-if-changed=build.rs");
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:16:9
|
16 | println!(
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:29:13
|
29 | println!("cargo:rustc-cfg=freebsd10")
| ^^^^^^^
```
bumping `llvmPackages_git` to match `llvmPackages_15`; this will let us
continuing bringing `llvmPackages_git` to parity with `llvmPackages_15`
without needing to invest time and effort into getting the current
llvmPackages_git's commit's test suite to pass under all the platforms,
etc.
this will also allow us to begin diffing derivations between
`llvmPackages_15` and `llvmPackages_git` as a way of tracking down
remaining differences between the package sets
Some Flutter packages require additional attribute values to be added to buildFlutterApplication, to add things like libraries and environment variables.
To prevent duplication in applications that use the packages, a repository of package overrides is kept. buildFlutterApplication will look for package overrides for each dependency, and apply them by calling overrideAttrs on itself.
Flutter application derivations can add dependencies and build flags, but it's not as easy during development.
As an alternative to nix-shell, a custom Flutter wrapper can be built with dependencies required by projects.
This feature builds on the existing build environment setup techniques required for Linux desktop support, so is fairly cheap to maintain.
This brings the following benefits:
- Artifacts missing in the SDK tarball (such as prebuilts for linux-aarch64) can be obtained
- Artifacts can be patched more granularly (e.g. libflutter_linux_gtk is patchelf-ed for GTK3, and the linux-aarch64 assets have a postPatch to add some missing files)
- Minimal Flutter packages can be generated (e.g. mkFlutterApp only needs prebuilts for desktop Linux, and developers that don't care for desktop Linux can exclude the artifacts and dependencies)
It also paves the way for including manually built engine facts.
Many nim packages regressed on darwin after 31254120db, which upgrade nim to 1.6.12. The cause of the breakage is that the nim standard library was changed to link against the Security framework when using the system rng on darwin. Notably not *all* nim packages were broken by this, since packages that don't use this part of the standard library don't need the framework to build.
This commit adds the Security framework to the depsTargetTargetPropagated for the compiler wrapper, since the standard library isn't fully functional without it.
Our rustc package is not universal, because we only build std for the
host and target platforms. This means that a build graph where cross
is involved will end up with multiple rustc packages in it, so it
would be helpful to have a way to tell them apart, just like we do for
e.g. gcc.
When cross compiling, buildPackages.cargo uses a rustc that can build
for both the build and host platforms. This was not true of
buildPackages.clippy, so it was not possible to use clippy for a cross
target. Now it is.
I've modified clippy.nix to use rustc from rustPlatform, so we only
have to add a single override in default.nix.
Flutter 3.5.0 adds a check to make sure that the Flutter and Dart tool executables are inside the SDK directory.
This does not play nicely with the wrapping and linking techniques used to package it. It is also impossible for there to be an issue related to binary locations, as everything is set up properly in the derivation.
The internal artifacts should be used, as they have been patched to use Nix libraries.
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>
Now that Flutter artifacts are patched, there is no need for a FHS at runtime or any stage of the build process.
Those relying on it for the Android SDK should look at https://github.com/tadfisher/android-nixpkgs.
This allows SDK artifacts (including build tools and libraries) to use the right interpreter and library locations, abolishing the need for a FHS or post-build patches.
`autoPatchelf` has been used through `autoPatchelfHook`, instead of the `autoPatchelf` command on just the artifact directory, due to the latter method not patching interpreter paths (https://discourse.nixos.org/t/trying-to-use-autopatchelf/24003).
Co-authored-by: FlafyDev <flafyarazi@gmail.com>
Co-authored-by: gilice <gilice@proton.me>
Co-authored-by: hacker1024 <hacker1024@users.sourceforge.net>
