BoomMicrophone/nixpkgs-suyu
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
nixpkgs-suyu/pkgs/development/compilers/llvm/3.4/llvm.nix

96 lines
2.3 KiB
Nix
Raw Normal View History

llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
{ stdenv
, fetch
llvm_34: fix build with glibc 2.26
2017-11-10 20:16:11 +01:00
, fetchpatch
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
, perl
, groff
, cmake
llvm_34: use python2
2016-11-09 16:05:53 +01:00
, python2
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
, libffi
LLVM: Get binutils plugin header from libbfd
2017-10-30 19:56:34 +01:00
, libbfd
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
, libxml2
, valgrind
, ncurses
, version
llvm: Propagate ncurses and zlib Really shouldn't be needed with shared libs, should patch llvm-config Fixes #1601 Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-04 00:10:38 +01:00
, zlib
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 17:29:41 +02:00
, compiler-rt_src
llvm: add debug builds support
2015-10-03 13:16:41 +02:00
, debugVersion ? false
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
}:
let
llvmPackages: maintenance update to 3.4.2 Updated all that was released: llvm, clang, and libc++.
2014-06-20 00:22:38 +02:00
src = fetch "llvm" "1mzgy7r0dma0npi1qrbr1s5n4nbj1ipxgbiw0q671l4s0r3qs0qp";
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
in stdenv.mkDerivation rec {
name = "llvm-${version}";
unpackPhase = ''
unpackFile ${src}
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 17:29:41 +02:00
mv llvm-${version}.src llvm
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
sourceRoot=$PWD/llvm
llvm+clang: maintenance update 3.4 -> 3.4.1 Slightly hacky for clang at some points, as directory names change strangely.
2014-05-10 17:29:41 +02:00
unpackFile ${compiler-rt_src}
mv compiler-rt-* $sourceRoot/projects/compiler-rt
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
'';
llvm: Don't depend on Python on Darwin There already is a Python in /usr/bin, so we don't need to build another one.
2014-09-23 13:13:53 +02:00
buildInputs =
llvmPackages_34.llvm: fix output of llvm-config now llvm-config --libnames and llvm-config --libfiles output the proper files.
2017-05-23 18:10:19 +02:00
[ perl groff cmake libxml2 libffi python2 ] /*
clang/llvm: Fewer build-time dependencies Such as valgrind, dejagnu, tcl/tk, ...
2014-10-11 22:04:03 +02:00
++ stdenv.lib.optional stdenv.isLinux valgrind */;
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
llvm: Propagate ncurses and zlib Really shouldn't be needed with shared libs, should patch llvm-config Fixes #1601 Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-04 00:10:38 +01:00
propagatedBuildInputs = [ ncurses zlib ];
llvmPackages_34.llvm: fix output of llvm-config now llvm-config --libnames and llvm-config --libfiles output the proper files.
2017-05-23 18:10:19 +02:00
patches = stdenv.lib.optionals (!stdenv.isDarwin) [
# llvm-config --libfiles returns (non-existing) static libs
llvmPackage_{3.4,3.5,3.7,3.8,3.9}: fix output of llvm-config llvm-config is a tool to output compile and linker flags, when compiling against llvm. The tool however outputs static library names despite libllvm is build as shared library on nixos. This was fixed for llvm 3.4, 3.5 and 3.7. For llvm 3.8 and 3.9 it printed the library extension twice (.so.so). This was fixed in 4.0 and the patch is backported to 3.8 and 3.9 in this pull request. ``` $ for i in 34 35 37 38 39; do echo "\nllvm-$i"; nix-shell -p llvmPackages_$i.llvm --run 'llvm-config --libnames'; done llvm-34 libLLVMInstrumentation.so libLLVMIRReader.so libLLVMAsmParser.so ... llvm-35 libLLVMLTO.so libLLVMObjCARCOpts.so libLLVMLinker.so libLLVMipo.so ... llvm-37 libLLVMLTO.so libLLVMObjCARCOpts.so libLLVMLinker.so libLLVMBitWriter.so ... llvm-38 libLLVM-3.8.1.so llvm-39 libLLVM-3.9.so ``` fixes #26713
2017-06-16 17:52:58 +02:00
../fix-llvm-config.patch
llvmPackages_34.llvm: fix output of llvm-config now llvm-config --libnames and llvm-config --libfiles output the proper files.
2017-05-23 18:10:19 +02:00
];
llvm_34: fix build with glibc 2.26
2017-11-10 20:16:11 +01:00
postPatch = stdenv.lib.optionalString (stdenv ? glibc) ''
(
cd projects/compiler-rt
patch -p1 -F3 < ${
fetchpatch {
name = "sigaltstack.patch"; # for glibc-2.26
url = https://github.com/llvm-mirror/compiler-rt/commit/8a5e425a68d.diff;
sha256 = "0h4y5vl74qaa7dl54b1fcyqalvlpd8zban2d1jxfkxpzyi7m8ifi";
}
}
sed -i "s,#include <pthread.h>,&\n#include <signal.h>,g" \
lib/asan/asan_linux.cc
)
'';
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
# hacky fix: created binaries need to be run before installation
preBuild = ''
mkdir -p $out/
ln -sv $PWD/lib $out
'';
cmakeFlags = with stdenv; [
llvm: add debug builds support
2015-10-03 13:16:41 +02:00
"-DCMAKE_BUILD_TYPE=${if debugVersion then "Debug" else "Release"}"
llvm: Add support for grsecurity
2013-12-17 01:34:52 +01:00
"-DLLVM_BUILD_TESTS=ON"
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
"-DLLVM_ENABLE_FFI=ON"
llvm-3.4: enable RTTI (close #8289)
2015-06-11 00:45:24 +02:00
"-DLLVM_REQUIRES_RTTI=1"
LLVM: Get binutils plugin header from libbfd
2017-10-30 19:56:34 +01:00
"-DLLVM_BINUTILS_INCDIR=${libbfd.dev}/include"
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
"-DCMAKE_CXX_FLAGS=-std=c++11"
llvmPackages_34.llvm: fix output of llvm-config now llvm-config --libnames and llvm-config --libfiles output the proper files.
2017-05-23 18:10:19 +02:00
] ++ stdenv.lib.optional (!stdenv.isDarwin) "-DBUILD_SHARED_LIBS=ON";
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
llvm: Add support for grsecurity
2013-12-17 01:34:52 +01:00
postBuild = ''
rm -fR $out
paxmark m bin/{lli,llvm-rtdyld}
paxmark m unittests/ExecutionEngine/JIT/JITTests
paxmark m unittests/ExecutionEngine/MCJIT/MCJITTests
paxmark m unittests/Support/SupportTests
'';
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
enableParallelBuilding = true;
passthru.src = src;
meta = {
description = "Collection of modular and reusable compiler and toolchain technologies";
homepage = http://llvm.org/;
LLVM: Fix licensing metadata, closes #22679. (#22681) * All projects are available under NCSA license, other than dragonegg. * "Runtime" projects are dual-licensed under both NCSA and MIT: libc++, libc++abi, compiler-rt * I don't mention MIT for compiler-rt as we only build it as part of LLVM.
2017-02-11 23:13:29 +01:00
license = stdenv.lib.licenses.ncsa;
Unmaintain a bunch of packages
2015-07-01 14:11:05 +02:00
maintainers = with stdenv.lib.maintainers; [ lovek323 raskin viric ];
llvm-3.4: Try to fix build on darwin Signed-off-by: Shea Levy <shea@shealevy.com>
2014-02-03 01:47:59 +01:00
platforms = stdenv.lib.platforms.all;
llvm: Split llvmFull into separate derivations 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>
2014-01-21 02:19:53 +01:00
};
}
Reference in a new issue Copy permalink