-split-sections replaced -split-objs with following upsides:
1) -split-objs adds considerable overhead to compile time
2) combined with stripping, it causes issues when cross-compiling
For upstream see https://ghc.haskell.org/trac/ghc/ticket/8405
This is supported only for Linux/Windows using ld linker.
GHC master also turns on -split-sections by default.
Example using stack:
Without splitting
$ du /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion/completions
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share
23416 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/bin
23420 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
With -split-objs
$ du /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
20632 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/bin
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion/completions
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share
20636 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
With -split-sections
$ du /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion/completions
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share
20672 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/bin
20676 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
Note: you currently need following overrides to build stack on 802:
vector-algorithms = dontCheck super.vector-algorithms;
path-io = doJailbreak super.path-io;
stack = doJailbreak super.stack;
Note: Should also work on GHC 8.0.1, but I'm being careful here.
We could backport later on.
This fix doesn't actually fix the cabal bug (see #16357), but it does
cause other bugs (see #20476)
Fixes#20476
This reverts commit b89fa5fd5c, reversing
changes made to e4b146b041.
This reverts commit ec8b816154. The change told
the Cabal build system to use the hash-part of $out as the internal identifier
for the library it's building (rather than generating such an ID itself). While
a good idea in theory, this choice had an unfortunate side-effect: When Cabal
links libraries X, Y, and Z into an executable, then the generated binary
contains their respective IDs. Now, Nix finds those strings and treats them as
an indication that there is a *run-time dependency* on the corresponding store
paths. This means that the generated executable will always depend on the store
paths of all the Haskell libraries that went into it, even when linked
statically.
This commit fixes a problem that occurs with externally linked haskell
libraries on Darwin. It does this by adding the libraries to the
--extra-lib-dirs flag and the DYLD_LIBRARY_PATH environment variable.
Without this patch, attempts to install at least some of the packages
that start to use setupHaskellDepends (mostly gtk-related packages)
results in collisions:
building path(s) ‘/nix/store/63k5smns43f5r2ad8wcc242x0gwd70m3-ghc-8.0.1’
collision between `/nix/store/k18i1nm5hgnb82y9w2g9hmlwhk3szjld-ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi' and `/nix/store/0rwhbwsg9kmywgbrib2bs29p2hmi80za-Cabal-1.24.0.0/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi'
builder for ‘/nix/store/vrjkfpm8sb96m9i5k74h8vn0rwddgy4v-ghc-8.0.1.drv’ failed with exit code 25
This would appear to me to be a consequence of setupHaskellDepends
entries being added to propagateBuildInputs. It is sufficient in the
cases I'm familiar with (taffyBar), and I think correct, to simply add
it to the otherBuildInputs.
hydraPlatforms now defaults to the value of meta.platforms rather than
defaulting to ghc.meta.hydraPlatforms. This solution is, in fact, still
sub-optimal. See https://github.com/NixOS/nixpkgs/issues/9608 for further
details.
A derivation of the Hackage package "foo" is called "haskell-foo" if it is a
library, but only "foo" if it is an executable (without a library). This
distinction used to be fine when Haskell packages where visible to operations
like "nix-env -qa" or "nix-env -i", but after our switch to Haskell NG it has
no more purpose. Consequently, this patch removes the name prefix from all
Haskell packages -- every Haskell package is now called exactly like it's
called on Hackage.
Closes https://github.com/NixOS/nixpkgs/pull/9538.
This also:
1 Builds Setup.hs with ghcjs, which (among other things) defines
__GHCJS__ and ghcjs_HOST_OS during pre-processing.
2 Fixes ghc-paths to point at ghcjs and use NIX_GHCJS_* env-vars.
3 Boots ghcjs into $prefix/lib/$compiler.
hydra.nixos.org serves broken binaries because of our favorite non-deterministic
package IDs in GHC bug. :-( Re-building everything from scratch seems like the
easiest way to recover.
We disabled this to prevent users from accidentally running nix-build on
an 'env' attribute, but in fact the ability to use those in combination
with "nix-shell -p" is quite useful, so the restriction is lifted.
The updated and jailbroken Cabal file must be in place before the
'patchPhase' hook is run, otherwise we cannot use that hook to patch the
Cabal file! Resolves https://github.com/NixOS/nixpkgs/issues/5922.
As an added bonus, this change makes the "jailbreakPhase" obsolete.
Packages that provide 32 and 64-bit libraries in the same store path are rare
and usually require manual overrides anyway. It seems pointless to try and
guess proper settings for them. The effect is that we'll end up with bogus
settings that take more effort to correct that it takes to configure proper
settings in the first place. Point in case: haskell-cuda and it's configuration
for "cudatools".
Fixes https://github.com/NixOS/nixpkgs/issues/6564.
The presence of this attribute allows us to recognize Haskell derivations.
Furthermore, we can use it to distinguish libraries from executables (which is
useful for the code that's generating the wrapper).
This makes the attribute (a) consistent with "doCheck" and friends and (b)
avoids the double negation "noHaddock = false" meaning "doHaddock = true".
Fixes https://github.com/NixOS/cabal2nix/issues/63.
I thought that [1] could be fixed by ensuring that ncurses is available in the
environment (because ghc exports it as a propagateBuildInput), and indeed that
change fixed *some* build failures we've had before. However, the same error
still occurs with other packages, like hledger [2] and Agda [3]. Frankly, I
have no idea why those packages fail and others don't. But clearly the fix was
inadequate, so I'm reverting commit a8076c76.
[1] https://github.com/NixOS/nixpkgs/issues/5616
[2] http://hydra.cryp.to/build/372451/nixlog/1/raw
[2] http://hydra.cryp.to/build/373161/nixlog/1/raw
Required adding a flag to the generic builder to build Setup.hs with
core packages even if there is an override in buildInputs, to break
circular dependencies.
The builder creates a temporary package.conf.d database in $TMP that
contains everything required to build the current package (i.e. the
transitive closure of the package's propagated build inputs). These
files are no longer installed, however, we just install the package.conf
file for the package we're actually building. This means that
package.conf.d directory in $out won't have collisions anymore, which
simplifies the with-packages-wrapper.nix a bit.
