[PATCH] D109192: [WIP/DNM] Support: introduce public API annotation support

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 5 13:47:33 PDT 2021


MaskRay added a comment.

If I am to summarize the state. The currently ELF build models are:

- default: `libLLVMSupport.a`
- `-DBUILD_SHARED_LIBS=on`: `libLLVMSupport.so`
- `-DLLVM_LINK_LLVM_DYLIB=on`: `libLLVM-14git.so`

Windows dynamic linking doesn't work.

From

> - minimal set of interfaces required for llvm-ar (archiver/librarian)
> - minimal set of interfaces required for lld (linker)
> - minimal set of interfaces required for clang (compiler)

it seems that the intention is to have `libLLVM{foo,bar,qux}.so` as the end state? And that is a controversial point among at least @compnerd, @jrtc27, and me.

I think the main purpose of this patch is to introduce these source file annotations (`LLVM_SUPPORT_ABI`) which will be the backbone of whatever dynamic linking mode we end up doing.
And we should ensure all parties are satisfied with the solution.
If you remove the behavior changing CMake changes, I will give a strong support.

---

Currently there is a hacking change in `lib/Support/CMakeLists.txt`: `add_llvm_component_library(LLVMSupport SHARED`
This breaks the regular `libLLVMSupport.a` build, so it should be fixed.

The `libLLVM{foo,bar,qux}.so` design is related to the Windows DLL limitation about 64k exported symbols.
To reduce platform differences (ELF/Mach-O vs PE/COFF), @compnerd wants the `libLLVM{foo,bar,qux}.so` design to be the way forward and the monolithic `libLLVM-14git.so` scheme to be dropped.
I agree with @lebedev.ri that such change needs to discussed on llvm-dev.
The `libLLVM-14git.so` scheme is adopted by multiple major Linux distributions with many LLVM dependent packages.
Such a split should not be taken lightly.

FWIW For my https://github.com/MaskRay/ccls/blob/master/CMakeLists.txt#L95 , I'll need to adjust

  if(LLVM_LINK_LLVM_DYLIB)
    target_link_libraries(ccls PRIVATE LLVM)

Other packages may need adaptation as well.
Personally I consider that ELF/Mach-O changing `libLLVM-14git.so` to cater to Windows DLL limitation unfortunate, but I can be convinced if the split argument (platform difference, maintenance cost consideration) is sufficiently strong.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109192/new/

https://reviews.llvm.org/D109192



More information about the llvm-commits mailing list