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.
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
I have no idea whether that's going to work, and I can't test it for
lack of access to a MacOS X machine, but think chances are pretty good
that this is going to succeed.
svn path=/nixpkgs/trunk/; revision=27751
There were two problems preventing GHC 7.0.2 from being built on MacOS. For
one, the 'configure' script automatically added the flag
-isysroot /Developer/SDKs/MacOSX10.5.sdk
to the command-line that's being passed to GCC. This setting doesn't work with
our GCC, and resulted in build errors because standard headers like <stdargs.h>
could no longer be found.
Secondly, the build depends on install_name_tool, which has been added as a
buildInput.
These changes trigger a re-build on all platforms, not just on Darwin. I
realize that this could have been avoided by adding some cruft. However, I
didn't want to add cruft, so there you are.
svn path=/nixpkgs/trunk/; revision=26513
