`pkgsBuildTarget` allows us to avoid repeated and confusing conditions.
The others merely provide clarity for one the foreign package set's
target platform matters.
This fixes cudatoolkit building on non-sandboxed system.
The cudatoolkit tests run each of the CUDA binaries as a small smoke
test just to make sure they all can at least somewhat run.
However, the `cuda-gdb` binary doesn't run correctly on non-sandboxed
systems because it picks up versions of Python from /usr/lib.
This PR disables the smoke tests for now. They should be re-enabled
when we figure out how to make them work for cuda-gdb on non-sandboxed
systems.
This PR is for #57939.
For the past couple of years, there has continued to be problems with having the PureScript compiler on nixpkgs building from Haskell packages it is not built against in its actual development and release. We have seen this issue come up multiple times here on nixpkgs, but this also causes numerous issues to be filed against the PureScript compiler repository. One example of an exchange that has occurred multiple times in the past: https://github.com/NixOS/nixpkgs/issues/53597https://github.com/purescript/purescript/issues/3571. As noted, the PureScript compiler is not on Stackage because it is not meant to be used as a library, and it does not update itself to the latest LTS and cut releases to match LTS releases.
Instead, I have begun maintaining my own derivation for the PureScript compiler (among other tools) in a small project here: https://github.com/justinwoo/easy-purescript-nix. Within are other reference and derivations for other tools commonly used in the PureScript ecosystem, updated to their respective newest releases. These derivations use the same releases that other Linux and OSX users use, along with the standard application of patchELF to provide for runtime dependencies such as zlib, gmp, and ncurses5. These derivations are now used by a variety of NixOS, non-NixOS Linux, and OSX users.
This commit then consumes the easy-purescript-nix derivation for the PureScript compiler and provides it in all-packages for consumption.
This caused some reverse dependencies of adoptopenjdk to depend on
adoptopenjdk's libfreetype, rather than the NixOS
libfreetype. For example: https://github.com/NixOS/nixpkgs/issues/57733
Now the derivation does not contain libfreetype.so . The JRE links to
nixpkg's freetype:
$ ldd /nix/store/9iyxm1nkn35xhjgri041r980z4p5ls5g-adoptopenjdk-hotspot-bin-11.0.2/lib/libfontmanager.so | grep -i freetype
libfreetype.so => /nix/store/ycbkq39cngzx19j829qzgdnw3mx3z78g-freetype-2.9.1/lib/libfreetype.so (0x0000795e30702000)
Souffle has seen some significant upgrades in the past few years and now
has trimmed and replaced several of its more expensive dependencies,
such as boost, openjdk, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
fetchFromGitHub and thus fetchzip hashes the contents of the archive and
not the archive itself. Unicode file names lead to different checksums
on HFS+ vs. other file systems because of Unicode normalisation
When building with -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON the compiler-rt
CMake configuration attempts to use CMAKE_*_COMPILER_TARGET variables,
which are usually only defined in cross-compilation mode.
You can build (partially) with LLVM toolchain using the useLLVM flag.
This works like so:
nix-build -A hello --arg crossSystem '{ system =
"aarch64-unknown-linux-musl"; useLLVM = true }'
also don’t separate debug info in lldClang
It doesn’t work currently with that setup hook. Missing build-id?
LLVM should be target independent because it will work with all
machine types. This is different from GCC where it needs to know what
target to build ahead of time.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
* llvm: build w/polly in-tree, optionally
Don't enable by default yet, defer rebuilds.
* top-level: llvm-polly, clang-polly
* bit hacky re:overrides
* need to explicitly set cmake flags for clang to link in polly
LLVM should be target independent because it will work with all
machine types. This is different from GCC where it needs to know what
target to build ahead of time.
