[cmake] Fix clang builds with BUILD_SHARED=ON and CLANG_LINK_CLANG_DYLIB=ON

[tstellar]

Summary

We were linking all the clang objects and shared libraries into
libclang-cpp.so, which was causing the command line options to be
registered twice.

[mgorny]

Got me a while to understand what you're saying. It's all high magic but looks reasonable enough.

[tstellar]

Ping.

[tstellar]

After thinking about this more, do we want to even try to support the BUILD_SHARED=ON + CLANG_LINK_CLANG_DYLIB=ON configuration? We don't support this in llvm.

[tstellar]

In D68520#1782387, @tstellar wrote:

After thinking about this more, do we want to even try to support the BUILD_SHARED=ON + CLANG_LINK_CLANG_DYLIB=ON configuration? We don't support this in llvm.

Actually, even if we don't support this in clang, we still need to fix this. Otherwise libclang-cpp.so will not be useable at all when clang has been built with BUILD_SHARED=ON .

[tstellar]

Ping. This bug is preventing upstream projects from using libclang-cpp.so, since building with -DENABLE_SHARED=ON is still common.

[mgorny]

Well, it looks correct to me. Not sure if it's the best approach but it can be refined in the future.

[beanz]

Seems reasonable.

[tstellar]

Rewrite patch to use cmake features available with cmake >= 3.4. The previous
version used a 3.6 feature: list(FILTER ...)

[merge_guards_bot]

Unit tests: pass. 62114 tests passed, 0 failed and 808 were skipped.

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

[mgorny]

clang/tools/clang-shlib/CMakeLists.txt

28

Any reason not to use if(${lib} MATCHES ...)?

https://cmake.org/cmake/help/v3.0/command/if.html

Not sure if ${} is needed, I get always confused by that.

[tstellar]

Address review comments

[tstellar]

clang/tools/clang-shlib/CMakeLists.txt

28

Thanks for the tip, I updated the patch to use this.

[tstellar]

Ping.

[mgorny]

Still LGTM.

clang/tools/clang-shlib/CMakeLists.txt

 # Building libclang-cpp.so fails if LLVM_ENABLE_PIC=Off
 if (NOT LLVM_ENABLE_PIC)
   return()
 endif()
 
 get_property(clang_libs GLOBAL PROPERTY CLANG_STATIC_LIBS)
 
 foreach (lib ${clang_libs})
   if(XCODE)
     # Xcode doesn't support object libraries, so we have to trick it into
     # linking the static libraries instead.
     list(APPEND _DEPS "-force_load" ${lib})
   else()
     list(APPEND _OBJECTS $<TARGET_OBJECTS:obj.${lib}>)
   endif()
   list(APPEND _DEPS $<TARGET_PROPERTY:${lib},INTERFACE_LINK_LIBRARIES>)
-  list(APPEND _DEPS $<TARGET_PROPERTY:${lib},LINK_LIBRARIES>)
+
+  # clang libraries are redundant since we are linking all the individual
+  # object files into libclang-cpp.so, so filter them out from _DEPS.
+  # This avoids problems with LLVM global data when building with
+  # BUILD_SHARED_LIBS=ON
+  # FIXME: We could use list(FILTER) with cmake >= 3.6
+  # FIXME: With cmake >= 3.15 we could use the generator expression
+  # $<FILTER:list,INCLUDE|EXCLUDE,regex>
+  get_target_property(interface ${lib} LINK_LIBRARIES)
+  if (interface)
+    foreach(lib ${interface})
+      if (NOT ${lib} MATCHES "^clang")
+        list(APPEND _DEPS ${lib})
+      endif()
+    endforeach()
+  endif()
 endforeach ()
 
 if (CLANG_LINK_CLANG_DYLIB)
   set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
 endif()
 
 add_clang_library(clang-cpp
                   SHARED
                   ${INSTALL_WITH_TOOLCHAIN}
                   clang-shlib.cpp
                   ${_OBJECTS}
                   LINK_LIBS
                   ${_DEPS})