diff options
| author | Saleem Abdulrasool <compnerd@compnerd.org> | 2025-02-05 15:15:36 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-02-05 15:15:36 -0800 |
| commit | 1901f4ac8eb1ddd8df822841a48b818c496aa2ad (patch) | |
| tree | 7c462e9d509985d9484e002dc114a79ce8a1b9a0 /clang/lib/CodeGen/CodeGenModule.cpp | |
| parent | 0d7ee520d3a9b8997adf8eaaa22b33db9659d94e (diff) | |
| download | llvm-1901f4ac8eb1ddd8df822841a48b818c496aa2ad.zip llvm-1901f4ac8eb1ddd8df822841a48b818c496aa2ad.tar.gz llvm-1901f4ac8eb1ddd8df822841a48b818c496aa2ad.tar.bz2 | |
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).
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions