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