Needed to build an executable that uses OpenMP with clang. This
includes a header file and a library that clang will link into an
executable whose source makes use of ‘omp‘ pragmas.
This is in preparation for the LLVM 4 upgrade (which gets more strict
about e.g., return false in xcbuild itself) and also for using xcbuild
more extensively in the Darwin stdenv bootstrap process, which is why I
killed the unnecessary gcc dependency in the toolchain. llvm-cov pretends
to be gcov anyway, so we're fine.
Splits outputs in clang like we do in 3.8 and 4.0 to avoid runtime
dependency on Python in the main derivation.
I also disable TSAN on Darwin to maintain consistency with 4.0, which
disables it because it forces an unfree dependency in the stdenv.
Split outputs because there's no point in keeping a reference to Python
and it causes trouble during the Darwin stdenv bootstrap. There's also
an unnecessary dependency on LLVM in libc++ which causes us to rebuild
LLVM several more times than necessary during bootstrap, and an awkward
dependency on XPC in the TSAN that we turn off. This is in preparation
for using LLVM 4 in the Darwin stdenv and by default across nixpkgs.
This reflects upstream versioning change, and allows
us to replace 4.0 with 4.1 (which is now a minor revision)
without changing the attribute name.
Thanks to @vcunat for the idea.
On 3.9 the substituteInPlace is equivalent to the patch,
hopefully this is a slightly more robust way to make
the same substitution for the 4.0 version.
Apply this change unconditionally for consistency across versions,
even if the changed strings are unused on other platforms.
Discussion:
https://github.com/NixOS/nixpkgs/pull/22970#discussion_r101926144
* 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.
Modern compiler will issue a following error whenever '#include <string>'
is done:
/nix/store/yxpwamjdapjcp53mmsdh1j2c9bc26h4k-libc++-3.7.1/include/c++/v1/string:1938:44:
error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible<allocator_type>::value)'
basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& __a)
^
/nix/store/yxpwamjdapjcp53mmsdh1j2c9bc26h4k-libc++-3.7.1/include/c++/v1/string:1326:40:
note: previous declaration is here
_LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a)
^
1 error generated.
This happens because modern clang is more strict about checking
exception specification for forward declaration and definition.
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?r1=242056&r2=242623&diff_format=h
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
Fixes#18840: too large closure of mesa_drivers.
Tested atop 16.09:
- clang compiles a hello-world app;
- mesa seems to link OK;
- ispc builds.
Size comparison:
- 80 MB of full llvm-3.7 on 16.03;
- 200 MB of full llvm-3.9 on 16.09 before this patch;
- 50 MB of libLLVM after this commit.
It's a long build and generally painful to split into smaller commits,
so I apologize for lumping many changes into one commit but this is far
easier.
There are still several outdated parts of the darwin stdenv but these
changes should bring us closer to the goal.
Fixes#18461
- Enable the shared library build on darwin by default to match other
platforms.
- Fix the dylib file's name in the store
- Symlink a versioned name as some tooling expects this.
Make Obj public in llvm's IntrusiveRefCntPtr
This fixesNixOs/nixpkgs#15974
It's not a nice fix, as it's really clang's problem. The proper fix
should modify clang's usage of IntrusiveRefCntPtr.
The hashes for libc++ and libc++abi were wrong.
There was also an incompatibility with nixpkgs on darwin which is now
weakly worked around: the "os_trace" macro changed definition in the OS
X development SDK since version 10.9 as used by nixpkgs. LLVM 3.8 uses
the new version, which I am temporarily replacing with a printf on
darwin as it is only used in one minor location.
vcunat's review:
- let's not switch the default versions of llvm* for now
- the only changes I see is adding python to clang's buildInputs
and using the big so-file as discussed in #12759
(BUILD_SHARED_LIBS -> LLVM_LINK_LLVM_DYLIB)
- in future it will be nice to split libLLVM into a separate output
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Package changes from 3.6:
- CMake exports patch no longer necessary
- Cosmetic purity patch fix
- Build libc++ with private libc++abi headers visible from sources
- Work around bugs in lldb's configure scripts
This corrects linkage failures arising from missing -lc++abi and
resolves "unused argument" warnings arising due to -stdlib=libc++
serving no purpose when search paths are being supplied explicitly.
Also use recurseIntoAttrs only on the default version (instead of only on 3.4).
The "self" variants (stil) don't build and they're inconsistent
versions. /cc @shlevy (fea2266290).
This corrects linkage failures arising from missing -lc++abi and
resolves "unused argument" warnings arising due to -stdlib=libc++
serving no purpose when search paths are being supplied explicitly.
lldb-3.6 is working (just waiting on a staging fix to merge), so let's just
mark this broken until we decide to nuke 3.5 all together.
Fixes#6636 refs #6668
Attrnames and package names should be as close as possible to avoid confusion.
I took care not to confuse the two mpc things during the mass-replace,
so hopefully I suceeded (tarball still builds).
- 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)
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
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>
The 3.4 code was tested preliminary in x-updates,
described by 2e4eab1228.
Updates to llvm break builds of dependent packages (in all cases I've seen),
and often upstream isn't too fast in porting to the newest version.
Consequently, it seems better to keep more versions (two ATM),
both in one file to share eventual changes.
Also, using versioned llvm_* attributes is proposed because of this.
