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.
This change brings development feedback loop improvement
from a couple of ghc rebuilds to only one for working on generic
builder.
To completely eliminate the rebuilds, use two nixpkgs clones
and point boot packages to the unmodified one.
- Patch all executables and libraries, while skipping scripts. Base at
least uses libiconv, so should need this too---I suspect it wasn't a
problem before as we got away with the immpurity.
- Rather than hardcoding the symlinks to add, do one per mach-o as
needed
TEMP no -L no script
The newer to-be-added binaries have relative RPATHs that we'll break if
we try to `patchelf` before installation. We instead us LD_LOAD_LIBRARY
during the installation, which avoids needing to change the RPATH
temporarily.
One should do this when needed executables at run time. It is more
honest and cross-friendly than refering to binutils directly, if one
neeeds the default binary tools for the target platform, rather than
binutils in particular.
This reverts commit dfb0f25484, reversing
changes made to 7f8ff02437. These changes broke
the ghcWithPackages wrapper:
nix-shell -p "haskellPackages.ghcWithPackages (ps: [ps.mtl])" --run "ghc-pkg list mtl"
/nix/store/szz84j5k1dy3jdashis6ws28d8l8zxxb-ghc-8.0.2-with-packages/lib/ghc-8.0.2/package.conf.d
(no packages)
The build calls ar(1) in a way the tool doesn't like:
ar q cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi64.o src/x86/unix64.o src/x86/ffi.o src/x86/sysv.o
ar: creating cru
ar: .libs/libffi.a: No such file or directory
make[4]: *** [Makefile:717: libffi.la] Error 1
This may have become an issue after some recent binutils update; I'm not sure.
If you want to override the source but the major version changes (ie 8.1
-> 8.3) then you also have to modify the version. Otherwise the build
will fail with difficult to understand errors, making version a
parameter makes it easy to override.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
It would otherwise result into undefined referenecs for some functions
in the base when using the gold linker:
error: undefined reference to 'sqrt'
Fixes https://github.com/bos/double-conversion/pull/17
Previously ghc option -optl=-lm was used for packages depending on
such functions, but that could result into
fatal error: cannot mix -r with dynamic object /nix/store/7crrmih8c52r8fbnqb933dxrsp44md93-glibc-2.25/lib/libm.so.6
in some situations like profiling builds.
Patch was prepared by Michael Bishop and Niklas Hambüchen.
Closes https://github.com/NixOS/nixpkgs/pull/27584.
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
The approach taken to add this package was to port over the definitions
currently existing for HEAD, and making the necessesary changes to get
this building.
The Haskell package set associated with this compiler doesn't yet
guarantee that all or most of the packages successfully build with this
new compiler, but that will improve over time after this GHC 8.2.1
is officially released and the ecosystem catches up.
See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
If the flag enableIntegerSimple is true GHC will be build with the GPL-free but
slower integer-simple library instead of the faster but GPLed integer-gmp
library.
The attribute `pkgs.haskell.compiler.integer-simple."${ghcVersion}"` provides a
GHC compiler build with `integer-simple`.
Similarly, the attribute `pkgs.haskell.packages.integer-simple."${ghcVersion}"`
provides a package set supporting `integer-simple`.
Closes https://github.com/NixOS/nixpkgs/pull/22121.
Closes https://github.com/NixOS/nixpkgs/issues/5493.
Fixes#20281
"Since GHC 8.0, the User’s Guide is authored in ReStructuredText (or ReST
or RST, for short) a rich but light-weight mark-up language aimed at
producing documentation. The Sphinx tool is used to produce the final
PDF and HTML documentation."
- http://ghc.readthedocs.io/en/8.0.1/editing-guide.html
The $lib output refers to the terminfo database in $out, which is about
10x larger than the ncurses shared library. Splitting these outputs
saves a small amount of space for any derivations that use the terminfo
database but not the ncurses library, but we do not have evidence that
any such exist.
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
The new GHC version contains a patch [1] that passes linker and compiler flags
to GCC via response files rather than directly on the command-line. This is
supposed to be beneficial on Windows and other platforms that have trouble
dealing with long argument lists. On NixOS, however, this feature breaks the
flag handling provided by gcc-wrapper [2] and therefore causes the entire GHC
build to fail.
This issue has been reported upstream at [3]. It's not clear yet how to remedy
this problem, but until we've figured that out we just don't pass compiler flags
in response files on NixOS to fix https://github.com/NixOS/nixpkgs/issues/10752.
[1] 296bc70b5f
[2] https://github.com/NixOS/nixpkgs/issues/11762
[3] https://ghc.haskell.org/trac/ghc/ticket/11147
Fixes#9044, close#9667. Thanks to @taku0 for suggesting this solution.
Now we have no modes starting with `/` or `+`.
Rewrite the `-perm` parameters of find:
- completely safe: rewrite `/0100` and `+100` to `-0100`,
- slightly semantics-changing: rewrite `+111` to `-0100`.
I cross-verified the `find` manual pages for Linux, Darwin, FreeBSD.
I'm not sure what was the compatibility problem before that commit,
but ghc at least builds now on both x86 Linux platforms
(and this commit doesn't cause a rebuild on x86_64-linux).
The name of the GHC derivation must match the name and version tuple GHC
uses to identify itself, because the withPackages wrapper uses that name
to construct installation library paths etc., and those paths must match
those constructed by the compiler. If we add another tag to the name
that GHC itself doesn't use, then the paths assumed to exist by the
wrapper are wrong.
