Skip to content

Meta issue to track changes for adding plugin and LLVM_BUILD_LLVM_DYLIB support for Windows #109483

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
22 of 40 tasks
fsfod opened this issue Sep 20, 2024 · 4 comments
Open
22 of 40 tasks

Meta issue to track changes for adding plugin and LLVM_BUILD_LLVM_DYLIB support for Windows #109483

fsfod opened this issue Sep 20, 2024 · 4 comments
Labels
cmake Build system in general and CMake in particular metabug Issue to collect references to a group of similar or related issues. platform:windows

Comments

@fsfod
Copy link
Contributor

fsfod commented Sep 20, 2024 •
edited by vgvassilev
Loading

This is meta issue to track adding support for building LLVM and Clang as a shared library on windows and to also allow the use on plugins for Support clang plugins on Windows GSOC project. This will mostly be achieved by adding explicit visibility macros to public API surface that will dllexport'ed. These changes will also benefit non windows platforms by reducing the numbers of exported symbols when the default symbol visibility is set to hidden at a latter time.
Some rational for these changes is explained in this old LLVM discourse post Supporting LLVM_BUILD_LLVM_DYLIB on Windows.

With the current code merged in it is possible build a LLVM DLL using clang-cl, but not all the required symbols exported yet so tools aren't buildable. A branch with most of the changes from the open PR's merged in can be found here along with full visibility macros to create a working windows build with working plugins for LLVM and Clang. The CMake options to use are -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_BUILD_LLVM_DYLIB_VIS=ON -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON

LLVM

Clang

Clang Tooling Fixes and improvements

  • Update Clang to store source location for explicit function template instantiation definitions and declarations so tool can annotate them and not guess
  • Make FrontendAction::BeginSourceFile virtual so proxy Actions work correctly
  • Fix non usable API in FixItRewriter to access computed changes without writing a file
@EugeneZelenko EugeneZelenko added cmake Build system in general and CMake in particular platform:windows and removed new issue labels Sep 20, 2024
@h-vetinari h-vetinari mentioned this issue Oct 16, 2024
Open
fsfod added a commit to fsfod/llvm-project that referenced this issue Oct 28, 2024
@fsfod
[ORC] Switch to new visibility macros for JIT debug symbols
cec0aa9 
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and __jit_debug_register_code so
there exported even if LLVM is not built as a shared library.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on windows llvm#109483.
@fsfod fsfod mentioned this issue Oct 28, 2024
Merged
fsfod added a commit to fsfod/llvm-project that referenced this issue Nov 5, 2024
@fsfod
[ORC] Switch to new visibility macros for JIT debug symbols
81f9ff1 
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and __jit_debug_register_code so
there exported even if LLVM is not built as a shared library.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on windows llvm#109483.
@annamthomas
Copy link
Contributor

hi @fsfod , I'm having trouble building my local downstream fork of LLVM which uses dynamic build and link (i.e. these options are present: -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON).

If I revert back to before the first change landed in this series, it builds completely fine.
The reason is that we have some dynamic dependencies between our downstream library and LLVM and when building those files, it complains of same issue as reported here: #107687

i.e.

[02:35:10] #include "llvm/CodeGen/GenVT.inc"
[02:35:10]          ^~~~~~~~~~~~~~~~~~~~~~~~
[02:35:10] 1 error generated.

Is there any workarounds you can suggest for this? I've tried adding the -DLLVM_BUILD_LLVM_DYLIB_VIS=ON but it does not help.

@fsfod
Copy link
Contributor Author

fsfod commented Nov 5, 2024

I'm not sure why my changes would cause that file not to be generated. I did notice there was a merged PR thats looks similar to your issue #109306

@annamthomas
Copy link
Contributor

I'm on truck but that didn't fix it.

After multiple iterations, what I see finally helped is reverting the change:
283c2c8: "[TableGen] Add explicit symbol visibility macros to code generated (#107873)"

And I can build on trunk. How does the visibility macros work actually?

@fsfod
Copy link
Contributor Author

fsfod commented Nov 5, 2024

For non windows and i think mingw it would be turned in to __attribute__((visibility("default"))) which is redundant atm because the default symbols visibility has not yet been changed to hidden. On windows platforms it should be empty unless LLVM_BUILD_LLVM_DYLIB_VIS is used.

@EugeneZelenko EugeneZelenko added the metabug Issue to collect references to a group of similar or related issues. label Nov 5, 2024
vgvassilev pushed a commit that referenced this issue Nov 7, 2024
@fsfod
[ORC] Switch to new visibility macros for JIT debug symbols (#113848)
c87d198 
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
a shared library.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows #109483.
Groverkss pushed a commit to iree-org/llvm-project that referenced this issue Nov 15, 2024
@fsfod @Groverkss
[ORC] Switch to new visibility macros for JIT debug symbols (llvm#113848
7611bb2 
)

Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
a shared library.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows llvm#109483.
@nikic nikic mentioned this issue Nov 20, 2024
Open
This was referenced Feb 18, 2025
Merged
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
This was referenced Feb 20, 2025
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
@mcbarton mcbarton mentioned this issue Feb 28, 2025
Open
compnerd pushed a commit that referenced this issue Mar 11, 2025
@andrurogerz
[llvm] replace static_assert with std::enable_if_t in ilist_node_impl (…
4f60f45 
…#127722)

##  Purpose
Remove `static_assert` in `ilist_node_impl::isSentinel` and
conditionally include the functino using `std::enable_if_t` instead.

## Background
This fix is necessary to support building LLVM as a Windows DLL, tracked
by #109483.

The `static_assert` in `ilist_node_impl::isSentinel` fails when
compiling LLVM as a Windows DLL with the options `-D
LLVM_BUILD_LLVM_DYLIB=ON -D LLVM_BUILD_LLVM_DYLIB_VIS=ON -D
LLVM_LINK_LLVM_DYLIB=ON`:
```
S:\llvm\llvm-project\llvm\include\llvm/ADT/ilist_node.h(151): error C2338: static_assert failed: 'Use ilist_sentinel_tracking<true> to enable isSentinel()'
S:\llvm\llvm-project\llvm\include\llvm/ADT/ilist_node.h(151): note: the template instantiation context (the oldest one first) is
S:\llvm\llvm-project\llvm\include\llvm/IR/SymbolTableListTraits.h(113): note: see reference to class template instantiation 'llvm::SymbolTableListTraits<llvm::Function>' being compiled
S:\llvm\llvm-project\llvm\include\llvm/IR/SymbolTableListTraits.h(69): note: see reference to class template instantiation 'llvm::simple_ilist<ValueSubClass>' being compiled
        with
        [
            ValueSubClass=llvm::Function
        ]
S:\llvm\llvm-project\llvm\include\llvm/ADT/simple_ilist.h(87): note: see reference to class template instantiation 'llvm::ilist_sentinel<llvm::ilist_detail::node_options<T,true,false,llvm::ilist_detail::extract_tag<>::type,false,llvm::ilist_detail::extract_parent<>::type>>' being compiled
        with
        [
            T=llvm::Function
        ]
S:\llvm\llvm-project\llvm\include\llvm/ADT/ilist_node.h(301): note: see reference to class template instantiation 'llvm::ilist_node_impl<OptionsT>' being compiled
        with
        [
            OptionsT=llvm::ilist_detail::node_options<llvm::Function,true,false,llvm::ilist_detail::extract_tag<>::type,false,llvm::ilist_detail::extract_parent<>::type>
        ]
S:\llvm\llvm-project\llvm\include\llvm/ADT/ilist_node.h(150): note: while compiling class template member function 'bool llvm::ilist_node_impl<OptionsT>::isSentinel(void) const'
        with
        [
            OptionsT=llvm::ilist_detail::node_options<llvm::Function,true,false,llvm::ilist_detail::extract_tag<>::type,false,llvm::ilist_detail::extract_parent<>::type>
        ]
```
Conditionally including the function using `std::enable_if_t` has the
same effect of preventing the function's use when
`is_sentinel_tracking_explicit=false`, but avoids the issue when
DLL-exporting downstream classes.

## Validation
Verified I no longer fail compilation due to the `static_assert` when
building LLVM on Windows 11 with the options `-D
LLVM_BUILD_LLVM_DYLIB=ON -D LLVM_BUILD_LLVM_DYLIB_VIS=ON -D
LLVM_LINK_LLVM_DYLIB=ON`.
This was referenced Apr 23, 2025
Open
Merged
@andrurogerz andrurogerz mentioned this issue Apr 23, 2025
Draft
compnerd pushed a commit that referenced this issue May 12, 2025
@andrurogerz
[llvm] annotate interfaces in llvm/Support for DLL export (#136014)
9c5f451 
## Purpose

This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Support` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.

## Background

This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).

The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.

The following manual adjustments were also applied after running IDS on
Linux:
- Add `#include "llvm/Support/Compiler.h"` to files where it was not
auto-added by IDS due to no pre-existing block of include statements.
- Add `LLVM_ABI` to Windows-only code (auto generated with IDS on
Windows)
- Explicitly make classes non-copyable where needed to due IDS adding
`LLVM_ABI` at the class level
- Add `LLVM_TEMPLATE_ABI` and `LLVM_EXPORT_TEMPLATE` to exported
instantiated templates
- Add `LLVM_ABI_FRIEND` to a small number of `friend` function
declarations
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
- Add `LLVM_ABI` functions defined via X-macro

## Validation

Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:

- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cmake Build system in general and CMake in particular metabug Issue to collect references to a group of similar or related issues. platform:windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fsfod @EugeneZelenko @annamthomas