<div dir='auto'>Great! We are looking forward to test your patches and DLLs.<div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Jan</div></div><div class="gmail_extra"><br><div class="gmail_quote">Dne 19. 3. 2020 19:32 napsal uživatel Stephen Crane via cfe-dev <cfe-dev@lists.llvm.org>:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I was able to successfully build and use both x86 and x64 DLLs on<br>
Windows 10 (MSVC 2019) with the following cmake invocation:<br>
cmake ../llvm -GNinja -DLLVM_ENABLE_PROJECTS=llvm;clang<br>
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PDB=ON<br>
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_TARGETS_TO_BUILD=X86<br>
-DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl -DLLVM_ENABLE_RTTI=Off<br>
-DLLVM_BUILD_LLVM_DYLIB=On -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE</p>
<p dir="ltr">I had to make a few changes to the build system (mostly commenting out<br>
checks preventing building DLLs on Windows). I'd be happy to prep<br>
patches to enable this mode properly in the LLVM cmake scripts, so we<br>
can discuss the merits of that option separately.</p>
<p dir="ltr">- stephen</p>
<p dir="ltr">On Wed, Mar 18, 2020 at 2:39 PM Michael Kruse <llvm@meinersbur.de> wrote:<br>
><br>
> Cmake also supporte the option WINDOWS_EXPORT_ALL_SYMBOLS for msvc. It<br>
> just creates a .def (list of symbols to export when linking a dll)<br>
> file including all symbols . LLVM's extract_symbols.py does something<br>
> similar.<br>
><br>
> Michael<br>
><br>
><br>
> Am Mi., 18. März 2020 um 16:35 Uhr schrieb Martin Storsjö <martin@martin.st>:<br>
> ><br>
> > On Wed, 18 Mar 2020, Michael Kruse via cfe-dev wrote:<br>
> ><br>
> > > Am Mi., 18. März 2020 um 12:51 Uhr schrieb Stephen Crane <sjc@immunant.com>:<br>
> > >> On Wed, Mar 18, 2020 at 9:23 AM Michael Kruse <llvm@meinersbur.de> wrote:<br>
> > >> > Windows DLLs have a limit of 2^16 exported symbols, that LLVM<br>
> > >> > unfortunately exceeds.<br>
> > >><br>
> > >> Would the individual libclang* libraries (e.g. libclangAST,<br>
> > >> libclangParse, etc.) exceed this limit? I'll do some experimental<br>
> > >> builds and see what I can determine.<br>
> > ><br>
> > > BUILD_SHARED_LIBS is also not supported on Windows, but I don't know<br>
> > > whether for the same reason.<br>
> ><br>
> > It's not supported when building with MSVC (or with Clang in MSVC mode),<br>
> > as it requires dllexport attributes on all symbols to be visible in the<br>
> > external interface of the DLL (or a def file listing all the exported<br>
> > symbols), and the interfaces of all the internal libraries aren't<br>
> > decorated with such attributes.<br>
> ><br>
> > If building with a MinGW toolchain (either GCC/binutils based, or<br>
> > Clang/lld based), it can export all symbols if none are marked<br>
> > specifically for export with dllexport attributes - and BUILD_SHARED_LIBS<br>
> > should work in this configuration (at least builds with it enabled<br>
> > succeeded last I tested maybe 7 weeks ago).<br>
> ><br>
> > // Martin<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br>
</p>
</blockquote></div><br></div>