[all-commits] [llvm/llvm-project] 1901f4: CodeGen: support static linking for libclosure (#1...

[Saleem Abdulrasool via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1901f4ac8eb1ddd8df822841a48b818c496aa2ad
      https://github.com/llvm/llvm-project/commit/1901f4ac8eb1ddd8df822841a48b818c496aa2ad
  Author: Saleem Abdulrasool <compnerd at compnerd.org>
  Date:   2025-02-05 (Wed, 05 Feb 2025)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Basic/CodeGenOptions.def
    M clang/include/clang/Driver/Options.td
    M clang/lib/CodeGen/CGBlocks.cpp
    M clang/lib/Driver/ToolChains/Clang.cpp
    M clang/lib/Frontend/CompilerInvocation.cpp
    M clang/test/CodeGen/blocks-windows.c

  Log Message:
  -----------
  CodeGen: support static linking for libclosure (#125384)

When building on Windows, dealing with the BlocksRuntime is slightly
more complicated. As we are not guaranteed a formward declaration for
the blocks runtime ABI symbols, we may generate the declarations for
them. In order to properly link against the well-known types, we always
annotated them as `__declspec(dllimport)`. This would require the
dynamic linking of the blocks runtime under all conditions. However,
this is the only the only possible way to us the library. We may be
building a fully sealed (static) executable. In such a case, the well
known symbols should not be marked as `dllimport` as they are assumed to
be statically available with the static linking to the BlocksRuntime.

Introduce a new driver/cc1 option `-static-libclosure` which mirrors the
myriad of similar options (`-static-libgcc`, `-static-libstdc++`,
-static-libsan`, etc).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications