[cfe-dev] Distributing static C++ clang libs on Windows

[Tom Stellard via cfe-dev]

On 03/26/2020 02:39 PM, Stephen Crane wrote:
> 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.
> 

If you look at this commit[1], I went through the targets
and explicitly marked all the symbols that needed to be public.
I'm not sure if this does better or worse than extract_symbols.py,
but I think it would be reasonable to start doing this in more
places throughout the code, e.g. in llvm/lib/CodeGen.

As LLVM maintainers for Fedora/RHEL, we also have an interest in reducing
the number of exported symbols as this helps make LTO optimizations
more effective.

-Tom

[1] https://github.com/llvm/llvm-project/commit/0dbcb3639451a7c20e2d5133b459552281e64455


> 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
>>
>>
>