Re-apply the build fix from <https://github.com/NixOS/nixpkgs/issues/2089>,
because apparently the underlying issue has not been fixed.
According to <https://github.com/elm-lang/Elm/issues/384>, Elm's release
archive comes with a Setup.hs that cannot compile an Elm release. Duh!
Replacing the custom Setup.hs file with a dummy version fixes this issue.
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.
Copy-pasta error, and compcert doesn't really make sense on Darwin or
64bit linux (it's callPackage_i686 anyway).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This also includes support for the verification tools I'm using. Cryptol
2 is still the default obviously.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This comes with several extra libraries, including GraphSCC, monadLib,
presburger, process and smtLib, all required as build dependencies. But
otherwise totally automated via cabal2nix.
Next up is CVC4 (a total pain in the ass to package) for proving/SAT
support.
I have another WIP branch for the unfree 1.x series which I may (or may
not) add later as it has external verification tech at the moment.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
- mark llvm34 as broken on darwin (so it doesn't install by default with nix-env)
- don't use our gcc for llvm_34 (might fix the build)
- switch also clang default to 3.3 on darwin (llvm was before)
These are packages for precompiled ARM microcontroller compilers from
https://launchpad.net/gcc-arm-embedded.
[Bjørn: modify commit message (add paragraph).]
This is a workaround to avoid the error: "java.io.IOException: RSA premaster
secret error".
In Java Web Start and the Java web plugin, there seems to be a Java policy
that prevents untrusted code from being loaded, and (probably for security
reasons) it doesn't like the files in the JDK's lib/icedtea/jre/lib/ext
directory to be symlinks.
Worked around it by copying those files instead of symlinking them.
When using -fsanitize=... options clang implicitly
links binary to static libraries which are part of
llvm, but expects them to be found under clang prefix
fsharp: Upgrade to fsharp-3.0
[ Shea: I'm merging thoughtpolice's commits without further testing
beyond code inspection, as I believe their work has proven itself ]
upgrade Mono -> 3.2.8 + LLVM support
[ Shea: I'm merging thoughtpolice's commits without further testing
beyond code inspection, as I believe their work has proven itself ]
On MinGW, we're passing these programs to the configure script, but this
obviously won't work for non-autoconf-based projects.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
Cross-compiling stuff against Mac OS X's CoreFoundation won't work
without ObjC support, and we don't want to compile commandline utilities
only, right?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's finally hook everything into the existing cross-building
infrastructure. We're using --with-sysroot instead of --with-headers
here, because the XCode SDK contains references to /usr/lib.
I've tried to patch those references, but unfortunately (at least with
install_name_tool) it isn't possible to change those refernces in stub
dylibs.
So after bugging @tpoechtrager with annoying questions (thanks again), I
think my initial approach (patching the SDK itself and/or regenerating
the dylib stubs) was way to complicated so I ended up with this
implementation.
Also, I've added a condition to binutilsCross to use cctools if the libc
is set to libSystem. This might need some cleanups someday, mainly to
figure out how to properly bridge cctools and binutils.
So, as an example on how to cross-compile GNU Hello to Darwin, you can
use something like this:
(import <nixpkgs> {
crossSystem = {
config = "x86_64-apple-darwin13";
arch = "x86_64";
libc = "libSystem";
platform = {};
};
}).hello.crossDrv
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This adds LLVM support in Mono using their custom fork, based on LLVM
3.4svn upstream. Somehow, it's gone for a while without a patch to fix
the CMakeLists.txt in the fork...
The upstream commit is based on the mono3 branch.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This removes the need for hacks like stdenv.regenerate. It also
ensures that overrideGCC is now stackable (so ‘stdenv = useGoldLinker
clangStdenv’ works).
HotSpot uses the absolute path of libjvm.so to determine the java.home
property (ignoring $JAVA_HOME), which is in turn used by
ToolProvider.getSystemJavaCompiler() to load tools.jar. So we need to
do some trickery to ensure that if java gets invoked from the jdk
output (ratherthan the jre output), it finds libjvm.so in the jdk output.
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.
Now most packages in the llvm suite are built as separate derivations.
The exceptions are:
* compiler-rt must currently be built with llvm. This increases llvm's
size by 6 MB
* clang-tools-extra must be built with clang
In addition, the top-level llvm attribute is defaulted to llvm 3.4, and
llvm 3.3 must be accessed by the llvm_33 attribute. This is to make the
out-of-date packages obvious in the hope that eventually all will be
updated to work with 3.4 and 3.3 can be removed. I think we should keep
this policy in the future (latest llvm gets top-level name, the rest are
versioned until they can be removed).
The llvm packages (except libc++, which exception I will try to remove
on the next update) can all be accessed via the llvmPackages attribute,
and there are also aliases for the packages that already existed (llvm,
clang, and dragonegg).
Signed-off-by: Shea Levy <shea@shealevy.com>
Some packages in the llvm suite (e.g. compiler-rt) cannot be built
separate from the build of llvm, and while some others (e.g. clang) can
the combined build is much better tested (we've had to work around
annoying issues before). So this puts llvm, clang, clang-tools-extra,
compiler-rt, lld, lldb, and polly all into one big build (llvmFull).
This build includes a static llvm, as dynamic is similarly less tested
and has known failures.
This also updates libc++ and dragonegg. libc++ now builds against
libc++abi as a separate package rather than building it during the
libc++ build.
The clang purity patch is gone. Instead, we simply set --sysroot to
/var/empty for pure builds, as all impure paths are either looked up in
the gcc prefix (which we hard-code at compile time) or in the sysroot.
This also means that if NIX_ENFORCE_PURITY is 0 then clang will look in
the normal Linux paths by default, which is the proper behavior IMO.
polly required an updated isl. When stdenv-updates is merged, perhaps we
can update the isl used by gcc and avoid having two versions.
Since llvm on its own is now separate from the llvm used by clang, I've
removed myself as maintainer from llvm and will leave maintenance of
that to those who are interested in llvm separate from clang.
Signed-off-by: Shea Levy <shea@shealevy.com>
