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.
The compiler should not expect to have dynamic versions of all libraries
available, because that configuration doesn't play along nicely with statically
linked libraries.
Fixes https://github.com/NixOS/nixpkgs/issues/6399.
These versions have been removed:
- 6.4.2-binary.nix
- 6.4.2.nix
- 6.6.1.nix
- 6.8.2.nix
- 6.8.3.nix
- 6.10.1-binary.nix
- 6.10.1.nix
- 6.10.2.nix
- 6.10.3.nix
- 6.11.nix
- 6.12.1-binary.nix
- 6.12.1.nix
- 6.12.2.nix
- 7.0.1.nix
- 7.0.2.nix
- 7.0.3.nix
- 7.2.1.nix
- 7.4.1.nix
- 7.6.1.nix
- 7.6.2.nix
- 7.8.3-binary.nix
As a rule of thumb, we keep the latest version in every major release. If
someone feels up to the task of fixing versions 6.4.x, 6.6.x, and 6.8.x, then
please don't hesitate to revive those builds.
Fixes https://github.com/NixOS/nixpkgs/issues/5630.
Originally, I thought that I can commit a "clean" patch -- even if it
triggers re-builds -- because those re-builds were triggered by the
ncurses patch to GHC anyway . That patch had to be reverted, though, so
now I'm rewriting this patch to avoid re-builds on Linux.
What a mess. :-(
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
Hydra generates a GHC closure for Darwin that for no apparent reason
contains an ancient, broken Haddock binary -- probably because of an
impurity in the build system. That bug makes those GHC binaries
unusable: <https://github.com/NixOS/nixpkgs/issues/2689>.
rts/StgCRun.c: In function 'StgRunIsImplementedInAssembler':
rts/StgCRun.c:208:1:
error: frame pointer required, but reserved
StgRunIsImplementedInAssembler(void)
^
In file included from includes/Stg.h:230:0:
0,
from rts/StgCRun.c:70:
includes/stg/Regs.h:323:20:
note: for 'Sp'
GLOBAL_REG_DECL(P_,Sp,REG_Sp)
^
includes/stg/Regs.h:174:54:
note: in definition of macro 'GLOBAL_REG_DECL'
#define GLOBAL_REG_DECL(type,name,reg) register type name REG(reg);
^
In this case, we also need to specify compilation flags to mark stacks as
non-executable, otherwise PaX will not allow ghc or binaries built by ghc
to run. This is what gentoo-hardened does as well.
It sucks, I know, but GHC just doesn't compile reliably when built with
some -j<n> option. :-( We have build errors because of apparent race
conditions all over the place on Hydra. This causes so much trouble for
users that it's not worth keeping this option enabled, IMHO.
1) The wrapper erroneously used the ghc-pkg flag "--package-db" instead of
"--global-package-db". The result was that packages installed locally in
~/.ghc and ~/.cabal were invisible to GHC. This has been fixed.
2) The wrapper now deals gracefully with an empty package set: if no package
is requested to be included in the wrapped environment, the wrapper just
installs a pristine GHC.
3) Correctly configure the "docdir" path returned by ghc-paths.
4) Added some comments that describe the idea behind our ghc-paths patches and
gives users same sample shell code that can be used to import our special
environment variables into the currently running shell, so that programs
outside of the wrapped environment can use them, too.
The ghcWithPackage expression now has an argument 'ignoreCollisions' that
allows users to disable the path collision check like so:
(pkgs.haskellPackages.ghcWithPackages (pkgs: with pkgs; [ haskellPlatform ])).override { ignoreCollisions = true; };
See d64917ad17
for a long and detailed discussion of why these path collisions may occur.
Haskell packages -- i.e. packages built by our Cabal builder -- invariably have
the attributes 'pname' and 'version'. We use the absence of these attributes to
recognize non-Haskell packages and filter them from the closed package set
generated by closePropagation. We do this so that the generated Haskell
environment won't contain paths like "/lib/libz.a", which are part of the
closure but have nothing to do with Haskell.
The previous scheme used the attribute 'ghc' to accomplish the same thing, but
unfortunately other packages to contain a 'ghc' attribute, too, like the
old-style ghc-wrapper. Including the ghc-wrapper in this environment is
pointless, obviously. The new approach filters the ghc-wrapper successfully.
* There now is full support for building Haskell packages as shared libraries
for GHC versions 7.4.2 or later. The Cabal builder recognizes the following
attributes:
- enableSharedLibraries configures Cabal to build of shared libraries in
addition to static ones. This option requires that all dependencies of
the package have been compiled for use in shared libraries, too.
- enableSharedExecutables configures Cabal to prefer shared libraries when
linking executables.
The default values for these attributes are arguments to the haskellPackages
expression.
* Haskell builds now run in a LANG="en_US.UTF-8" environment to avoid plenty
of build and test suite errors. Without this setting, GHC seems unable to
deal with the UTF-8 character encoding that's generally considered standard
in the Haskell world.
* The Cabal builder supports a new attribute 'testTarget' to specify the exact
set of tests to be run during the check phase.
* The ghc-wrapper attribute ghcVersion has been removed. Instead, we use the
ghc.version attribute, which exists in unwrapped GHC derivations, too.
The change was supposed to trigger a re-build to fix a broken GHC binary
on the Hydra build farm, but now it turns out that the cause for the
errors we're seeing isn't GHC: all kinds of (non-Haskell) packages are
broken.
Conflict in kerberos, which was updated both in master and in
stdenv-updates. Kept the stdenv-updates version, except pulled in the
enableParallelBuilding change from master.
Signed-off-by: Shea Levy <shea@shealevy.com>
Conflicts:
pkgs/development/libraries/kerberos/krb5.nix
The wrapper script accumulated some cruft over the last couple of months
because we did changes in freaky ways to avoid triggering re-builds of all
Haskell packages. Most of these kludges have been thrown out now.
This patch doesn't change the behavior of the wrapper except for one thing: the
internal helper scripts "ghc-get-packages.sh" and "ghc-packages.sh" are no
longer installed in the bin directory of the generated derivation.
The freaky implementation was done that way in order to avoid unnecessary
re-builds of all Haskell packages by changing the wrapper script used
internally in those builds.
See <https://github.com/NixOS/nixpkgs/pull/466> for further details.
Conflicts:
pkgs/development/libraries/libxslt/default.nix
Commit 1764ea2b0a introduced changes to libxslt
in an awkward way to avoid re-builds on Linux. This patch has been simplified
during this merge.
This predicate filters out packages that weren't created by the Cabal builder.
Doing that greatly reduces the likelihood of file collisions in the generated
environment, because Haskell packages tend to have a lot of propagated build
inputs.
For example, both zeromq 2.x and 3.x use the same names for their header files.
Users of haskell-zeromq don't need those headers, so we just don't include them
in the generated environment to avoid the collision that would otherwise occur
when haskell-zeromq 2.x and 3.x are installed into the same environment.
uses for its core libraries, so that these files integrate seamlessly into one
profile, living right next to each other. This change is eventually going to
simply our with-packages wrapper quite a bit.
When the ghc-paths library is compiled, the paths of the
compiler it is compiled with are being hardcoded in the
library (and can then be queried from other applications
using the library).
But on Nix, packages are compiled with ghc-wrapper, and
subsequently possibly used with a special version of ghc
generated for a particular environment of packages. So
one version of ghc-paths may potentially end up being
used by lots of different instances of ghc. The hardcoding
approach fails.
As a work-around, we now patch ghc-paths so that it allows
setting the paths that can be queried via environment
variables. Specific GHC environments can then set these
environment variables in the wrapper shell script that
invokes GHC.
This should at least partially solve issue #213.
Any attempt to instantiate these expressions on an unsupported platform is
going to 'throw' an error. The call to 'assert' doesn't add any value to
that (and generates less readable error messages, too). Further details are
available at <https://github.com/NixOS/nix/issues/56>.
I got the following error in 4 consecutive attempts:
building rts/dist/build/AutoApply.debug_o
building rts/dist/build/AutoApply.thr_o
rts_dist_HC rts/dist/build/AutoApply.debug_o
/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a/bin/ld: cannot find libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers_o_split/gmp-wrappers__1.o
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.p_o] Error 1
This change allows use of the with-packages wrapper in user profiles that are
being updated with "nix-env -u \*". The previous name this expression generated
was considered by Nix to be an older version of "ghc-7.0.4-wrapper", because
that name has a higher priority.
svn path=/nixpkgs/trunk/; revision=33325
Merge conflicts:
* unzip (almost trivial)
* dvswitch (trivial)
* gmp (copied result of `git merge`)
The last item introduced gmp-5.0.3, thus full rebuild.
+ensureDir->mkdir -p in TeX packages was catched by git but not svn.
svn path=/nixpkgs/branches/stdenv-updates/; revision=32091
I assumed that Hydra would arrive at that result anyway, but apparently
it doesn't: no x86_64-darwin builds have occurred despite the fact that
we can bootstrap on that architecture now.
svn path=/nixpkgs/trunk/; revision=28882
