nixpkgs#37012 and nixpkgs#37707 introduces the setup-hooks for libiconv, which inject `-liconv` into the `NIX_LDFLAGS`. This breaks horribly on windows where the linker end up having no idea how to linke `-liconv`. The configure.ac file specifically ignores libiconv on windows.
Something goes amiss in the configurePhase and binaries start picking up
system binaries and everything falls apart. Patch the configure script
to use a bourne shell out of the store, and things are happier.
Closes https://github.com/NixOS/nixpkgs/pull/40691.
The hack of using `crossConfig` to enforce stricter handling of
dependencies is replaced with a dedicated `strictDeps` for that purpose.
(Experience has shown that my punning was a terrible idea that made more
difficult and embarrising to teach teach.)
Now that is is clear, a few packages now use `strictDeps`, to fix
various bugs:
- bintools-wrapper and cc-wrapper
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
For some reason compiling the proper GHC from the binary one eventually
segfaults at some point.
Since it has never worked, just disable it and investigate later.
None of these old compilers are used anywhere in Nixpkgs, and keeping those
builds working in the face of regular updates of GCC, binutils, and whatnot is
too much effort for no obvious benefit.
These are taken from https://phabricator.haskell.org/D4388 (which is
against HEAD) and fix an inconsistency when building profiling
libraries on multiple machines that leads to linking failure.
- ghc versions 6.10.4, 6.12.3, and 7.2.2 are broken, and 6.10.2-binary is no
longer necessary after those versions have been dropped
- halvm version 2.4.0 hasn't compiled in a long time
- uhc version 1.1.9.4 hasn't compiled in a long time
Cabal2nix expects a --compiler flag that contains a Cabal Compiler description.
We used to use the compiler's derivation name for this, but this breaks when
cross-compiling due to the target suffix. Instead we add an explicit
haskellCompilerName attribute to Haskell compiler derivations.
GHC currently handles this stuff in a quite non-standard way, basically
taking prog var `FOO` to mean `FOO_FROM_TARGET`. It's because it
(wrongly) thinks from stage 2's perspective.
Tuomas Tynkkynen
Moritz Angermann
John Ericson
John Ericson
Vladimír Čunát
Jack Cummings
Frederik Rietdijk
Will Fancher
Peter Simons
Matthew Justin Bauer
Jan Malakhovski
Shea Levy
Kosyrev Serge
Ben Gamari
Ryan Trinkle