[cmake] Add a big warning about a libstdc++ issue

[labath]

Summary

Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++
versions prior to 4.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656, which make this class
unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work
around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not
seem like a good idea.

Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting
a to do a build which is suceptible to this problem and suggests possible alternatives. Right
now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen
occur during process shutdown), but there's no guarantee the situation will not change in the
future.

[labath]

I am adding everyone I think could be susceptible to this problem. It would be a good idea to check if you are still using libstdc++4.8 or older.

[krytarowski]

NetBSD is using newer libstdc++.

#include <set>
std::set<int> s = std::set<int>(std::allocator<int>());
int main() { return 0; }

Compiles (I need to specify the -std=c++11 option) and runs.

I will try it out in the context of LLDB CMake scripts.

[emaste]

FreeBSD 10.0 and later uses libc++. FreeBSD 9 has a very old libstdc++ and a very old gcc and can't build Clang 3.5 or later with the system compiler anyway. So this isn't a problem for FreeBSD.

I don't know cmake well enough to approve the change but the idea definitely sounds good to me.

[tberghammer]

looks good

cmake/modules/LLDBConfig.cmake

432 ↗

(On Diff #58584)

(nit): "be using linking to libstdc++"

[zturner]

Wondering if this should go in llvm. What do you think?

[labath]

In D20671#440868, @zturner wrote:

Wondering if this should go in llvm. What do you think?

I don't see any uses of weak_ptr in the llvm repository, so this issue should only affect lldb, I think.

[zturner]

Ok, lgtm then

lldb/trunk/cmake/modules/LLDBConfig.cmake

+include(CheckCXXSymbolExists)
+
 set(LLDB_PROJECT_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
 set(LLDB_SOURCE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/source")
 set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
 
 set(LLDB_LINKER_SUPPORTS_GROUPS OFF)
 if (LLVM_COMPILER_IS_GCC_COMPATIBLE AND NOT "${CMAKE_SYSTEM_NAME}" MATCHES "Darwin")
   # The Darwin linker doesn't understand --start-group/--end-group.
   set(LLDB_LINKER_SUPPORTS_GROUPS ON)
if (NOT LLDB_DISABLE_CURSES)
     endif ()
 
     # Add panels to the library path
     set (CURSES_LIBRARIES ${CURSES_LIBRARIES} ${CURSES_PANEL_LIBRARY})
 
     list(APPEND system_libs ${CURSES_LIBRARIES})
     include_directories(${CURSES_INCLUDE_DIR})
 endif ()
+
+check_cxx_symbol_exists("__GLIBCXX__" "string" LLDB_USING_LIBSTDCXX)
+if(LLDB_USING_LIBSTDCXX)
+    # There doesn't seem to be an easy way to check the library version. Instead, we rely on the
+    # fact that std::set did not have the allocator constructor available until version 4.9
+    check_cxx_source_compiles("
+            #include <set>
+            std::set<int> s = std::set<int>(std::allocator<int>());
+            int main() { return 0; }"
+            LLDB_USING_LIBSTDCXX_4_9)
+    if (NOT LLDB_USING_LIBSTDCXX_4_9 AND NOT LLVM_ENABLE_EH)
+        message(WARNING
+            "You appear to be linking to libstdc++ version lesser than 4.9 without exceptions "
+            "enabled. These versions of the library have an issue, which causes occasional "
+            "lldb crashes. See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656> for "
+            "details. Possible courses of action are:\n"
+            "- use libstdc++ version 4.9 or newer\n"
+            "- use libc++ (via LLVM_ENABLE_LIBCXX)\n"
+            "- enable exceptions (via LLVM_ENABLE_EH)\n"
+            "- ignore this warning and accept occasional instability")
+    endif()
+endif()