[cfe-dev] Distributing static C++ clang libs on Windows (was: Distributing libclang-cpp.dll for Windows in the pre-built downloads)
Stephen Crane via cfe-dev
cfe-dev at lists.llvm.org
Thu Mar 26 14:39:36 PDT 2020
I've been trying to get some sort of usable C++ API DLLs built on
Windows, but I'm giving up for now. My next question: would shipping
static C++ libraries and the corresponding headers on Windows be an
option at all? We already do this for the Linux binary distributions.
Not sure who would be best to weigh in on that. Hans, Tom, any
thoughts on this?
Over the last week I've spent quite a bit of time attempting to build
reasonably useful LLVM and clang-cpp DLLs on Windows. I got LLVM 9 to
build with just the frontend, no targets, but the number of symbols
has grown since then and exceeds 64K. It looks like clang-cpp is still
under the threshold, but not by much. We could probably pick out a
minimal set of LLVM frontend libraries necessary to link the clang
frontend DLL, but that doesn't seem like a good solution to me. So
unfortunately, unless someone spends time improving the
extract_symbols.py or another similar approach, DLLs don't look viable
on Windows.
Thanks,
Stephen
On Thu, Mar 19, 2020 at 1:22 PM <jan.rysavy at fine.cz> wrote:
>
> Great! We are looking forward to test your patches and DLLs.
>
> Best regards
> Jan
>
> Dne 19. 3. 2020 19:32 napsal uživatel Stephen Crane via cfe-dev <cfe-dev at lists.llvm.org>:
>
> I was able to successfully build and use both x86 and x64 DLLs on
> Windows 10 (MSVC 2019) with the following cmake invocation:
> cmake ../llvm -GNinja -DLLVM_ENABLE_PROJECTS=llvm;clang
> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PDB=ON
> -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_TARGETS_TO_BUILD=X86
> -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl -DLLVM_ENABLE_RTTI=Off
> -DLLVM_BUILD_LLVM_DYLIB=On -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE
>
> I had to make a few changes to the build system (mostly commenting out
> checks preventing building DLLs on Windows). I'd be happy to prep
> patches to enable this mode properly in the LLVM cmake scripts, so we
> can discuss the merits of that option separately.
>
> - stephen
>
> On Wed, Mar 18, 2020 at 2:39 PM Michael Kruse <llvm at meinersbur.de> wrote:
> >
> > Cmake also supporte the option WINDOWS_EXPORT_ALL_SYMBOLS for msvc. It
> > just creates a .def (list of symbols to export when linking a dll)
> > file including all symbols . LLVM's extract_symbols.py does something
> > similar.
> >
> > Michael
> >
> >
> > Am Mi., 18. März 2020 um 16:35 Uhr schrieb Martin Storsjö <martin at martin.st>:
> > >
> > > On Wed, 18 Mar 2020, Michael Kruse via cfe-dev wrote:
> > >
> > > > Am Mi., 18. März 2020 um 12:51 Uhr schrieb Stephen Crane <sjc at immunant.com>:
> > > >> On Wed, Mar 18, 2020 at 9:23 AM Michael Kruse <llvm at meinersbur.de> wrote:
> > > >> > Windows DLLs have a limit of 2^16 exported symbols, that LLVM
> > > >> > unfortunately exceeds.
> > > >>
> > > >> Would the individual libclang* libraries (e.g. libclangAST,
> > > >> libclangParse, etc.) exceed this limit? I'll do some experimental
> > > >> builds and see what I can determine.
> > > >
> > > > BUILD_SHARED_LIBS is also not supported on Windows, but I don't know
> > > > whether for the same reason.
> > >
> > > It's not supported when building with MSVC (or with Clang in MSVC mode),
> > > as it requires dllexport attributes on all symbols to be visible in the
> > > external interface of the DLL (or a def file listing all the exported
> > > symbols), and the interfaces of all the internal libraries aren't
> > > decorated with such attributes.
> > >
> > > If building with a MinGW toolchain (either GCC/binutils based, or
> > > Clang/lld based), it can export all symbols if none are marked
> > > specifically for export with dllexport attributes - and BUILD_SHARED_LIBS
> > > should work in this configuration (at least builds with it enabled
> > > succeeded last I tested maybe 7 weeks ago).
> > >
> > > // Martin
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
More information about the cfe-dev
mailing list