This allows the Go compiler in nixpkgs (eg. buildGoModule) to work with
crossSystem.config == mips-*, eg mips-unknown-linux-musl, and
succesfully generate Go MIPS binaries.
nix-build -A grpcurl --arg crossSystem '{ config = "mips-unknown-linux-musl"; }'
This unfortunately cannot currently be tested on qemu-mips as Go emits
ELF files that fail to execute correctly in qemu-user (see:
https://go-review.googlesource.com/c/go/+/239217, on track to land in Go
1.17). However, I have tested this on a physical MIPS device.
I have not been able to build anything using cgo (hit various
compilation errors in C dependencies), but considering
mips-unknown-linux-musl is not a support nixpkgs target this isn't that
surprising.
packagePaths changed between idris2 `v0.3.0` and `v0.4.0` and now
includes a version number in the path.
Fixesnixos/nixpkgs#130310
Co-authored-by: zseri <zseri.devel@ytrizja.de>
Co-authored-by: Mario Rodas <marsam@users.noreply.github.com>
The musl support for binary GHC 8.6.5 relied on ABI compat between musl
and glibc which is no longer the case: https://github.com/NixOS/nixpkgs/issues/129247
Since there is no upstream musl (alpine) bindist for GHC 8.6.5, we can
only accept that binary 8.6.5 is not possible with musl.
There are builds which rely on having the numeric version of gcc (eg "10.2.1")
declared in an environment variable.
Running 'arm-none-eabi-gcc --version' returns:
"arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)"
However, the attribute arm-none-eabi-gcc.version is "10-2020-q4-major",
from which there is no way to derive "10.2.1".
Contrast this with the attribute gcc.version which (at this time) gives "10.3.0".
By adding a numVersion attribute, consumers of this package can
correctly determine what GCC version is being executed.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Adds new package options:
* enableDocs
* enableHaddockProgram
to control whether to build Sphinx docs, and GHC haddocks and the
haddock program.
Unfortunately currently the building of the `haddock `program
and generating GHC docs are mixed into one option, see:
https://gitlab.haskell.org/ghc/ghc/-/issues/20077
Making Sphinx docs disableable, and disabling them by default
for Musl and cross builds, makes it much easier to provide these
builds without having to support Sphinx's enormous dependency
tree for those ways of building.
This addresses the fact that `ghc865Binary` segfaults on musl
(see #118731) because of the glibc+musl mix used in there.
With the previous commits, `ghc8102Binary` was changed to use
the musl-based bindist from GHC HQ instead, which works.
With this change, all nix Haskell compilers builds on musl:
NIX_PATH=nixpkgs=. nix-build --no-link --expr 'with import <nixpkgs> {}; { inherit (pkgsMusl.haskell.compiler) ghc884 ghc8104 ghc901 ghcHEAD; }'
This commit replaces the musl + glibc hackery in the GHC bindist
compiler by using the new musl based bindist that GHC HQ provides
(built on Alpine).
We could alternatively also use a nix-built musl boostrap compiler,
but it seems nicer to use the GHC HQ one for now.
This fixes the compiler built by
`pkgsMusl.haskell.compiler.ghc8102Binary` segfaulting (#118731)
since the commit
5e2311d2f - musl: 1.2.1 -> 1.2.2
concretely, musl commit
01c7920f - remove redundant pthread struct members repeated for layout purposes
which I suspect breaks some glibc/musl ABI compatibility that may have
existed accidentally until then.
The added
lib.optional stdenv.targetPlatform.isMusl "pie";
also fixes that the packaged bindist compiler cannot create a binary
in its `installCheck` phase (and overall); see detail explanation
in #129247.
With this check, we no longer don't notice when the upstream bindist
changes its dependencies (e.g. because a newer Debian version is used
that uses a new `ncurses` version).
inklecate is a command line compiler for the ink language, which is used
to make interactive narrative / choose-your-own-adventure style games.
More information about the ink language can be found at
https://github.com/inkle/ink
* Don't allow PONYPATH to override standard library (PR #3780)
* Fix bug where Flags.remove could set flags in addition to unsetting them (PR #3777)
* Allow Flags instances to be created with a set bit encoding (PR #3778)
* Fix "iftype" expressions not being usable in lambdas or object literals (PR #3763)
* Fix code generation for variadic FFI functions on arm64 (PR #3768)
The library override that was present in the code referred to a
name that isn't even used in current GHC bindists.
Tested with:
NIX_PATH=nixpkgs=. nix-build --no-link -A haskell.compiler.ghc8102Binary --argstr system i686-linux
- AMD GPU packages: AMD removed support for the RX5x0 GPUs from ROCm, so
I cannot test these packages anymore.
- A small number of GUI packages: I switched back to macOS on the
desktop for work reasons, so I cannot easily test these.
- broot: I took over maintainership from someone else, but do not really
use broot.
smlnjBootstrap seems to exist as a workaround for a failing x86_64-darwin build
of regular smlnj. Now this is fixed, the workaround can be removed.
(aarch64-darwin is being actively worked on by the smlnj project, and currently
is supported by neither derivation.)
v0.4.0:
- Added gmp as a build dependency
- Removed bootstrap-test (test still available and more general)
- Renamed bootstrap-build to bootstrap (bootstrap previously did
bootstrap-build and bootstrap-test)
With sphinx 4, interpreting the conf.py fails due to a decode
error: https://gitlab.haskell.org/ghc/ghc/-/issues/19962
The fix is an one line change which we have to backport from GHC
master.
9.2 and 8.10.6 will have a fix for this, GHC 9.0.1 and ghcHEAD
already have and GHC 8.10.4 has been patched in nixpkgs already.
With sphinx 4, interpreting the conf.py fails due to a decode
error: https://gitlab.haskell.org/ghc/ghc/-/issues/19962
The fix is an one line change which we have to backport from GHC master.
Thus ghcHEAD is not affected by this problem.
9.2 and 8.10.6 will most likely have a fix for this.
TODO: Patch 8.8.4 and 9.0.1