stdenvNoCC should not inject any C++ standard library, just as it
doesn't inject any C standard library. stdenv still does, but only
indirectly through stdenv.cc. Wrapped clangs can be simplified now that
they don't need to worry about clobbering CoreFoundation when replacing
the C++ standard library implementation.
This generally-good cleanup should assist with debugging some C++
failures in #26805.
This is very similar to what we had in bb0b0822ef.
The xlocale.h header is no longer existing in glibc version 2.26, so we
need to avoid including it.
I've tested building against all of the libcxx attributes of LLVM 3.5,
3.7, 3.8, 3.9, 4 and 5.
All of them succeeded except version 3.5, which failed because of an
unrelated issue (build of libc++abi has failed, one of its
dependencies), so I only verified whether the patch applies cleanly.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @vcunat
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
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.
* 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.
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.
