<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 20, 2014 at 3:54 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On 19/05/2014 04:41, Rafael Espíndola wrote:</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

TLDR; We _really_ want to calculate these dependencies at build time with<br>
LLVMBuild instead of annotating the source.<br>
</blockquote>
Is there a convenient way to feed this to link.exe?<br>
</blockquote>
<br></div>
We can pass in exports through a /def file, similar to exports with other linkers.<br>
<br>
To calculate the exports, someone will have to write a script/tool that collects undefined symbols, then goes through visible symbols in other modules to derive the export lists.<br>
<br>
That'll generate minimal export lists, tuned for each platform and configuration, permitting optimal dead stripping and optimisation. And it'll save us from the burden of annotating loads and loads of definitions in the source that only work for a few setups.</blockquote>
<div><br></div><div>It's an interesting idea, but I'm pretty opposed to this approach.</div><div><br></div><div>First, this approach doesn't work for exported data.  You need annotations to import data, and I can say from experience that we do this in LLVM.</div>
<div><br></div><div>Second, I tried to rig up something that exports all symbols with dumpbin once and it was ridiculously slow.  I think anything that tried to scrape imports of one set of object files from another would also be really slow.  Even if we used llvm-nm and made it fast, it'd be part of our build system.  Ew.</div>
<div><br></div><div>Third, suppose we want to build LLVMSupport.dll.  Now we need to build LLVMSupport.lib, then everything that uses LLVMSupport.dll, and then scrape imports from all those static archives or object files.  This is a *huge* web of dependencies.  Now building llvm-as.exe which dynamically links LLVMSupport.dll depends on building clangSema.lib.  That's a non-starter.</div>
<div><br></div><div>If we want to support DSOs exporting a C++ interface, IMO we should define the DSO boundary up front and use annotations.  I think the logical DSO boundaries would be LLVMSupport, LLVM, and Clang.</div>
</div></div></div>