[flang-commits] [flang] [llvm] [openmp] [Flang-RT] Fix GCC 15.1 Fortran Runtime libstdc++ Undefined Symbols (PR #157385)

[Patrick Simmons via flang-commits]

================
@@ -231,6 +231,26 @@ function (add_flangrt_library name)
       target_compile_options(${tgtname} PRIVATE
           $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions -fno-rtti -funwind-tables -fno-asynchronous-unwind-tables>
         )
+
+      # We define our own _GLIBCXX_THROW_OR_ABORT here because, as of
+      # GCC 15.1, libstdc++ uses (void)_EXC in its definition in order
+      # to silence a warning.
+      #
+      # This is a problem for us because some compilers, specifically
+      # clang, do not always optimize away that (void)_EXC even though
+      # it is unreachable since it occurs after a call to
+      # _builtin_abort().  Because _EXC is typically an object derived
+      # from std::exception, (void)_EXC, when not optimized away,
+      # causes a link reference to std::exception, and we do not want
+      # to link against std::exception since doing that would link us
+      # against the C++ runtime library, and we do not want to link
+      # the Fortran runtime against the C++ runtime.
----------------
linuxrocks123 wrote:

@Meinersbur I revised the comment in a way similar to your suggestion; please take a look.

Also, although I did mention .so version conflicts in the comment as the reason we don't want to link against libstdc++, are you sure that's really true?  The GNU .so files are forward compatible, so, as long as our users use a version at least as new as our build version, we should be fine there.  And, we do link the Fortran runtime against the GNU C runtime, which has the same forward-but-not-backward compatibility profile as the GNU C++ runtime.  So, I'm not sure .so conflicts would actually manifest.

My understanding was that we didn't want to link against libstdc++ because it's big and bulky and we just don't need it.

https://github.com/llvm/llvm-project/pull/157385