LGTM

We may also want to consider renaming LIBCXXABI_HERMETIC_STATIC_LIBRARY and LIBCXX_HERMETIC_STATIC_LIBRARY to LIBCXXABI_HIDE_SYMBOLS and LIBCXX_HIDE_SYMBOLS respectively for consistency.

LGTM

LGTM

I can push the change for you if you don't have commit permissions. What name and email would you like me to use?

LGTM thanks for looking into this!

D125597 should address the build error in compiler-rt.

LGTM

@ellis do you have time to land this change? This change should address https://github.com/llvm/llvm-project/issues/55125 so I'd like to see it landed.

In D124673#3512070, @MaskRay wrote:

In D124673#3512037, @paulkirth wrote:

Hi, Sorry for the late notification, but I think this change may not apply correctly to all configs.

We're seeing a breakage in Fuchsia's Clang CI builders: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8814329895908917697/overview

FAILED: lib/LineEditor/CMakeFiles/LLVMLineEditor.dir/LineEditor.cpp.o 
/b/s/w/ir/cache/goma/client/gomacc /b/s/w/ir/x/w/cipd/bin/clang++ --sysroot=/b/s/w/ir/x/w/cipd/linux -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/s/w/ir/x/w/staging/llvm_build/lib/LineEditor -I/b/s/w/ir/x/w/llvm-llvm-project/llvm/lib/LineEditor -I/b/s/w/ir/cache/vpython/79db7c/lib/python3.8/site-packages/tensorflow/include -I/b/s/w/ir/x/w/staging/llvm_build/include -I/b/s/w/ir/x/w/llvm-llvm-project/llvm/include -isystem /b/s/w/ir/x/w/staging/zlib_install/include -stdlib=libc++ -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/b/s/w/ir/x/w/staging/llvm_build=../staging/llvm_build -ffile-prefix-map=/b/s/w/ir/x/w/llvm-llvm-project/= -no-canonical-prefixes -O3 -DNDEBUG  -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -UNDEBUG -std=c++14 -MD -MT lib/LineEditor/CMakeFiles/LLVMLineEditor.dir/LineEditor.cpp.o -MF lib/LineEditor/CMakeFiles/LLVMLineEditor.dir/LineEditor.cpp.o.d -o lib/LineEditor/CMakeFiles/LLVMLineEditor.dir/LineEditor.cpp.o -c /b/s/w/ir/x/w/llvm-llvm-project/llvm/lib/LineEditor/LineEditor.cpp
/b/s/w/ir/x/w/llvm-llvm-project/llvm/lib/LineEditor/LineEditor.cpp:18:10: fatal error: 'histedit.h' file not found
#include <histedit.h>
         ^~~~~~~~~~~~

since the error is a missing header for histedit.h, and this change alters how libedit is found in CMake, I assume this is the root cause.

I'm guessing some part of the old CMake checks like the old HAVE_HISTEDIT_H may not have propagated correctly in all cases?

If this will be hard to fix, would you mind reverting until a fix is ready?

It's not clear to me that this patch caused the issue for you, so I don't think it is right to ask for a revert now. You need to provide more evidence.
lldb-x86_64-debian and lldb-cmake-standalone on https://lldb.llvm.org/resources/bots.html work well with the change.

Superseded by D125393.

LGTM

In D125393#3511394, @ldionne wrote:

Thanks a lot both @mstorsjo and @phosek for the comments. I've applied @mstorsjo's change (and made a similar change for static libraries). I also did it for libunwind.

@phosek I'm not sure I follow when you say that marking the object libraries as EXCLUDE_FROM_ALL is going to require some reworking elsewhere in LLVM. We are only marking the object libraries as EXCLUDE_FROM_ALL, and nobody outside the runtimes will be using them. The normal cxxabi_shared & friends targets will still be there, and they will still be built by default unless LIBCXXABI_ENABLE_SHARED=OFF.

LGTM

LGTM

In D125393#3507367, @mstorsjo wrote:

Thanks! Overall, this looks like it can work for me. The same two issues as I still had with D116689 (as discussed with @phosek there) exists here too:

• For mingw, I can't build cxxabi_shared, but I do need cxxabi_shared_objects for cxx_shared. @phosek suggested fixing this by always creating the cxxabi_shared_objects target, but adding the EXCLUDE_FROM_ALL property on it.

• As the line target_link_libraries(cxx_shared PUBLIC unwind_shared) is removed from cxx, builds with LIBCXXABI_USE_LLVM_UNWINDER, without LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY fail. This can be fixed (at least for my case, didn't test other cases) by moving that dependency from cxxabi_shared to cxxabi_shared_objects - so that it propagates to either cxxabi_shared or cxx_shared later.

I.e., to make it work for me, I made this change on top of it:

diff --git a/libcxxabi/src/CMakeLists.txt b/libcxxabi/src/CMakeLists.txt
index 6e22432759e6..04bee47deee7 100644
--- a/libcxxabi/src/CMakeLists.txt
+++ b/libcxxabi/src/CMakeLists.txt
@@ -152,10 +152,13 @@ if (NOT TARGET pstl::ParallelSTL)
 endif()
 
 # Build the shared library.
-if (LIBCXXABI_ENABLE_SHARED)
   add_library(cxxabi_shared_objects OBJECT ${LIBCXXABI_SOURCES} ${LIBCXXABI_HEADERS})
-  if (LIBCXXABI_USE_LLVM_UNWINDER AND LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY)
-    target_sources(cxxabi_shared_objects PUBLIC $<TARGET_OBJECTS:unwind_shared_objects>)
+  if (LIBCXXABI_USE_LLVM_UNWINDER)
+    if (LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY)
+      target_sources(cxxabi_shared_objects PUBLIC $<TARGET_OBJECTS:unwind_shared_objects>)
+    else()
+      target_link_libraries(cxxabi_shared_objects PUBLIC unwind_shared)
+    endif()
   endif()
   target_link_libraries(cxxabi_shared_objects PRIVATE cxx-headers ${LIBCXXABI_BUILTINS_LIBRARY} ${LIBCXXABI_SHARED_LIBRARIES} ${LIBCXXABI_LIBRARIES})
   target_link_libraries(cxxabi_shared_objects PUBLIC cxxabi-headers)
@@ -166,12 +169,11 @@ if (LIBCXXABI_ENABLE_SHARED)
       CXX_STANDARD_REQUIRED OFF
       COMPILE_FLAGS "${LIBCXXABI_COMPILE_FLAGS}"
       DEFINE_SYMBOL ""
+      EXCLUDE_FROM_ALL ON
   )
 
+if (LIBCXXABI_ENABLE_SHARED)
   add_library(cxxabi_shared SHARED $<TARGET_OBJECTS:cxxabi_shared_objects>)
-  if(LIBCXXABI_USE_LLVM_UNWINDER AND NOT LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY)
-    target_link_libraries(cxxabi_shared PUBLIC unwind_shared)
-  endif()
   set_target_properties(cxxabi_shared
     PROPERTIES
       LINK_FLAGS "${LIBCXXABI_LINK_FLAGS}"

(I guess the same change for always creating the cxxabi_static_objects, but with EXCLUDE_FROM_ALL, should be made too, but I just tested with the bare minimums for making this work for me.)

In D116689#3504337, @phosek wrote:

In D116689#3502709, @mstorsjo wrote:

In D116689#3502026, @phosek wrote:

I wonder if we could simplify things by always building cxxabi_static_objects and cxxabi_shared_objects but marking them as EXCLUDE_FROM_ALL?

That's probably the best solution for that - thanks!

I've realized that this also going to simplify our build so I like that direction. It's not entirely straightforward though because there are currently various parts of the build that assume that either static or shared libcxxabi is being built which need to be reworked.

In D116689#3502709, @mstorsjo wrote:

In D116689#3502026, @phosek wrote:

I wonder if we could simplify things by always building cxxabi_static_objects and cxxabi_shared_objects but marking them as EXCLUDE_FROM_ALL?

That's probably the best solution for that - thanks!

In D116689#3500263, @mstorsjo wrote:

This version breaks things for me; I'm building with LIBCXX_ENABLE_STATIC_ABI_LIBRARY and LIBCXXABI_USE_LLVM_UNWINDER but not LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY. In this case, there's no shared libcxxabi (I build with LIBCXXABI_ENABLE_SHARED=OFF), so libcxx would need to retain the code to link against the libunwind cmake target, it can't be carried transitively via libcxxabi (cxxabi_shared_objects). I.e. this case gets lost:

if(LIBCXXABI_USE_LLVM_UNWINDER AND NOT LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY)
   target_link_libraries(cxxabi_shared PUBLIC unwind_shared)
 endif()

I'll need some time to properly investigate this so I'm going to revert this change in the meantime.

In D116689#3497481, @mstorsjo wrote:

@phosek Do you have time to pick this up and complete it? It'd be essential for a build cleanup for Windows - but the patch itself is a bit too far outside of my cmake-fu.

LGTM after discussing this with @ldionne on Discord. We'll try to come up with a more general solution next.

LGTM

In D121175#3481547, @MaskRay wrote:

Probably no from my view, as I got another internal feedback that "this seems rather crufty".
It seems that it is the build system maintainer's responsibility. If you add -Wno-unknown-warning-option temporarily, after a new clang is rolled, you may remove -Wno-unknown-warning-option.

In D114115#3477967, @probinson wrote:

Lit is aware of zlib's presence or absence, you could use REQUIRES: zlib (or you might factor that bit out into its own test with the REQUIRES).

No longer needed, this is now the Clang default.

Rebase to trigger bots.

I'd be in favor of defaulting to an ERROR and providing an option to downgrade to a WARNING.

In D124474#3475550, @beanz wrote:

In D124474#3475539, @azharudd wrote:

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

My point here is that maybe you should move away from the legacy way of building now rather than improving it... Not sure how @phosek feels about this. I would personally very much prefer if we only had one way to build compiler-rt instead of the half dozen we have today.

LGTM

Another use case besides the one already described by @abrachet is better support for case preserving and case insensitive file systems.

LGTM

LGTM

LGTM