- 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.
