<div dir="ltr"><div>Thanks for starting!<br></div>Btw here is my CMD version:<br>
<p class="MsoNormal"><span lang="EN-US">cmd /Q
/V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F
"tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr
"_LLVM"') do (set symbolname=%e & echo !symbolname:~1!))"<br><br></span></p><p class="MsoNormal"><span lang="EN-US">You run it in the directory with all the llvm*.lib (yes the ThinLTO is excluded in this example but can be added easily i think)<br></span></p>
</div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-06 20:16 GMT+02:00 Jakob Bornecrantz <span dir="ltr"><<a href="mailto:wallbraker@gmail.com" target="_blank">wallbraker@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Made a bit of headway here: <a href="https://reviews.llvm.org/D35077" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D35077</a><br>
<br>
Cheers, Jakob.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Apr 6, 2017 at 2:34 PM, Alexander Benikowski<br>
<<a href="mailto:sebal007@googlemail.com">sebal007@googlemail.com</a>> wrote:<br>
> Maybe someone can use this as a startingpoint to add the windows-specific<br>
> commandblock which is triggered instead of the Darwin one together with a<br>
> proper setup of targets to have the libs build before.<br>
><br>
> 2017-04-06 14:30 GMT+02:00 Alexander Benikowski <<a href="mailto:sebal007@googlemail.com">sebal007@googlemail.com</a>>:<br>
>><br>
>> The following is an older commandline i used. Have a more recent one at<br>
>> home. But basically you can write it as batch and trigger it within a target<br>
>> during the build(never got targets into correct order, i am a cmake noob)<br>
>><br>
>> So for reference, i'll post this one and look for the recent one at<br>
>> home(if that didn't go down with my recent hdd crash):<br>
>><br>
>> cmd /Q /V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F<br>
>> "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do (set<br>
>> symbolname=%e & echo !symbolname:~1!))"<br>
>><br>
>> What it does:<br>
>><br>
>> For all *.lib files ina specific dir starting with LLVM call dumpbin.exe<br>
>> (tool from Visualstudio) and write all symbols with LLVM_ into a specific<br>
>> file<br>
>><br>
>><br>
>> 2017-04-05 20:40 GMT+02:00 Jakob Bornecrantz via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br>
>>><br>
>>> On Wed, Apr 5, 2017 at 5:20 PM, John Brawn <<a href="mailto:John.Brawn@arm.com">John.Brawn@arm.com</a>> wrote:<br>
>>> > We already half-have this, the LLVM_BUILD_LLVM_C_DYLIB cmake option<br>
>>> > builds<br>
>>> > a shared object which exports the llvm-c interface but it only works on<br>
>>> > Darwin.<br>
>>> ><br>
>>> > tools/llvm-shlib/CMakeLists.<wbr>txt is where how this is done is defined,<br>
>>> > and it<br>
>>> > looks like it does it by:<br>
>>> > * build LLVM.so<br>
>>> > * use nm+awk+sed to pick out the symbols starting with LLVM<br>
>>> > * build LLVM-C.so using a -reexport_library linker option<br>
>>> ><br>
>>> > I'm thinking that maybe we could make this not-darwin-specific by<br>
>>> > making<br>
>>> > use of utils/extract_symbols.py:<br>
>>> > * edit extract_symbols.py to add a --only_unmangled option (or maybe<br>
>>> > --only_prefix=LLVM or something like that)<br>
>>> > * on non-darwin use that instead of the existing command to get the<br>
>>> > symbols to export (or: make extract_symbols.py work on Darwin)<br>
>>> > * instead of building LLVM-C.so from LLVM.so using this<br>
>>> > -reexport_library<br>
>>> > option, instead build LLVM-C.so from the same libraries that LLVM.so<br>
>>> > is built from<br>
>>> > (where I use .so above, it also applies to .dll)<br>
>>> ><br>
>>> > John<br>
>>><br>
>>> Thanks for the info John!<br>
>>><br>
>>> I tried to enable LLVM_BUILD_LLVM_C_DYLIB on my linux machine<br>
>>> to play around a little bit. I disabled the APPLE check to get past that.<br>
>>> The config failed if I had BUILD_SHARED_LIBS also set to true.<br>
>>> If I tried that without the flag it complained about missing:<br>
>>> builddir/./lib/libLLVM.so<br>
>>><br>
>>> Which is a bit weird since it builds a lib/<a href="http://libLLVM-5.0svn.so" rel="noreferrer" target="_blank">libLLVM-5.0svn.so</a>.<br>
>>><br>
>>> I have to admit I'm a tiny bit in over my head here with the cmake<br>
>>> scripts here.<br>
>>><br>
>>> Cheers, Jakob.<br>
>>><br>
>>> ><br>
>>> >> -----Original Message-----<br>
>>> >> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@<wbr>lists.llvm.org</a>] On Behalf Of<br>
>>> >> Jakob Bornecrantz via llvm-dev<br>
>>> >> Sent: 05 April 2017 12:51<br>
>>> >> To: llvm-dev<br>
>>> >> Subject: Re: [llvm-dev] Shipping LLVM.dll for the C API with the<br>
>>> >> Windows<br>
>>> >> installer.<br>
>>> >><br>
>>> >> On Thu, Mar 30, 2017 at 4:46 PM, Jakob Bornecrantz<br>
>>> >> <<a href="mailto:wallbraker@gmail.com">wallbraker@gmail.com</a>> wrote:<br>
>>> >> > Hello list!<br>
>>> >> ><br>
>>> >> > So I'm wondering if there is a will to ship a DLL with the C API<br>
>>> >> > exported? LLVM currently ships with LTO.dll which has some C api<br>
>>> >> > functions exported, made from the export file tools/lto/lto.exports,<br>
>>> >> > so it would not be the first DLL LLVM shipped.<br>
>>> >> ><br>
>>> >> > Currently I (and the users of my project[1]) are building it<br>
>>> >> > ourselves<br>
>>> >> > using this script[2] derived from the LLVMSharp script[3]. Which<br>
>>> >> > adds<br>
>>> >> > a extra long step for all users of ours and other projects like<br>
>>> >> > LLVMSharp in order to use them.<br>
>>> >> ><br>
>>> >> > The resulting LLVM.dll exports 809 functions and weighs in at around<br>
>>> >> > 18mb, so it would make the installer larger. There is also the cost<br>
>>> >> > of<br>
>>> >> > maintaining a lists of export for the DLL, but hopefully we can use<br>
>>> >> > the llvm-echo to test it on the windows nodes so any failure to add<br>
>>> >> > new exports gets detected early.<br>
>>> >> ><br>
>>> >> > Now for the bike-shed questions, do we call it LLVM-c.dll or just<br>
>>> >> > LLVM.dll? Annotate all functions with a LLVM_EXPORT define or use a<br>
>>> >> > llvm-c.exports file?<br>
>>> >> ><br>
>>> >> > Thoughts and feedback welcome.<br>
>>> >> ><br>
>>> >> > Cheers, Jakob.<br>
>>> >> ><br>
>>> >> > [1] <a href="http://volt-lang.org" rel="noreferrer" target="_blank">http://volt-lang.org</a><br>
>>> >> > [2]<br>
>>> >> > <a href="https://github.com/VoltLang/GenLLVMDLLPy/blob/master/GenLLVMDLL.py" rel="noreferrer" target="_blank">https://github.com/VoltLang/<wbr>GenLLVMDLLPy/blob/master/<wbr>GenLLVMDLL.py</a><br>
>>> >> > [3]<br>
>>> >><br>
>>> >> <a href="https://github.com/Microsoft/LLVMSharp/blob/master/tools/GenLLVMDLL.ps1" rel="noreferrer" target="_blank">https://github.com/Microsoft/<wbr>LLVMSharp/blob/master/tools/<wbr>GenLLVMDLL.ps1</a><br>
>>> >><br>
>>> >> Ping? Any thoughts?<br>
>>> >><br>
>>> >> What would be the best way to proceed? My cmake-fu is very weak so any<br>
>>> >> pointers here from those knowledgeable and stakeholders in the code<br>
>>> >> would be greatly appreciated.<br>
>>> >><br>
>>> >> Cheers, Jakob.<br>
>>> >> ______________________________<wbr>_________________<br>
>>> >> LLVM Developers mailing list<br>
>>> >> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
>>> ______________________________<wbr>_________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>