❤️

Can the other 2 submodules be removed now then?

Actually removing them will break the build of older versions but they can surely be archived (made read-only).

I mean removed from the repo, so they are not cloned. Not removed from Github

Ah, of course yes ... forgot that, thanks!

Link error

Oct 30 14:17:21 ld.lld-15: error: undefined symbol: atomic_load
Oct 30 14:17:21 >>> referenced by refcount_c11.c:51 (../contrib/boringssl/crypto/refcount_c11.c:51)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::context::~context())
Oct 30 14:17:21 >>> referenced by refcount_c11.c:51 (../contrib/boringssl/crypto/refcount_c11.c:51)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::detail::engine::~engine())
Oct 30 14:17:21 >>> referenced by refcount_c11.c:51 (../contrib/boringssl/crypto/refcount_c11.c:51)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::detail::stream_core::~stream_core())
Oct 30 14:17:21 >>> referenced 363 more times
Oct 30 14:17:21 
Oct 30 14:17:21 ld.lld-15: error: undefined symbol: atomic_compare_exchange_weak
Oct 30 14:17:21 >>> referenced by refcount_c11.c:60 (../contrib/boringssl/crypto/refcount_c11.c:60)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::context::~context())
Oct 30 14:17:21 >>> referenced by refcount_c11.c:60 (../contrib/boringssl/crypto/refcount_c11.c:60)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::detail::engine::~engine())
Oct 30 14:17:21 >>> referenced by refcount_c11.c:60 (../contrib/boringssl/crypto/refcount_c11.c:60)
Oct 30 14:17:21 >>>               lto.tmp:(boost::asio::ssl::detail::stream_core::~stream_core())
Oct 30 14:17:21 >>> referenced 363 more times
Oct 30 14:17:21 clang: error: linker command failed with exit code 1 (use -v to see invocation)
Oct 30 14:17:21 ninja: build stopped: subcommand failed.

Declarations of C11 functions atomic_load() and atomic_compare_exchange_weak() are visible but no implementation exists. They are defined in "libcxx/include/atomic" and I suppose that compiler intrinsic __c11_atomic_compare_exchange_weak is not defined. Unfortunately, I currently have no idea how to fix that.

What is interesting is that in current master (without this PR), atomic_load() and atomic_compare_exchange_weak()
point to "llvm-project/clang/lib/Headers/stdatomic.h", at least in my IDE, e.g.

#define atomic_compare_exchange_weak(object, expected, desired) __c11_atomic_compare_exchange_weak(object, expected, desired, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST)

The alternative is to force-compile BoringSSL w/o atomics by commenting out the stuff after Automatically enable C11 atomics if implemented. in "contrib/boringssl/crypto/internal.h" and I doubt that the result would be any slower. But before doing so, maybe someone else has an idea?

@azat @alexey-milovidov Just wondering, perhaps you have an idea or explanation for the link failure libcxx and libcxxabi are build directly from the llvm-project submodule?

We are using old glibc without support for C11 (and we have to use the old glibc for compatibility).

Let's check why BoringSSL decided to use C11. It should not, and also we should not have any checks in CMakeLists (all the configuration has to be predefined).

Oct 30 14:17:21 ld.lld-15: error: undefined symbol: atomic_load

This should be fixed by #43166

We are using old glibc without support for C11 (and we have to use the old glibc for compatibility).

stdatomic.h is not provided by glibc, but by compiler.

TL;DR;

It started to fail because of __config, in particular how _LIBCPP_COMPILER_CLANG_BASED is set.

• In libcxx submodule that is upstream now it is set unconditionally - https://github.com/ClickHouse/libcxx/blob/9a457ab3c64a533a06922b386b284215c17ce627/include/__config#L39
• However in llvm submodule it is set only for C++ - https://github.com/ClickHouse/llvm-project/blob/bd0ba013354bbfb8db03eeb9b553d629b58f65ac/libcxx/include/__config#L202 (it is done under https://github.com/ClickHouse/llvm-project/blob/bd0ba013354bbfb8db03eeb9b553d629b58f65ac/libcxx/include/__config#L25)

And because of this it does not include non-c++ version of a header, the fix is obvious, CXX library should not be linked for C (headers and so on).

Also note that there is some trickery in the previous __config - https://github.com/ClickHouse/libcxx/blob/9a457ab3c64a533a06922b386b284215c17ce627/include/__config#L13-L23

P.S. once this will be solved there will be some issues with the problem that std::vector cannot work with opaque structures anymore - #42513 (comment)

@azat Thanks a lot for checking + the fix.

@kitaisreal This PR is ready, approve? Thanks.