<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 18, 2014 at 1:34 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On 16/05/2014 22:36, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
On Fri, May 16, 2014 at 11:49 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
<br>
On 16/05/2014 21:20, Richard wrote:<br>
<br>
In article <<a href="mailto:4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE@gmail.com" target="_blank">4FBFE344-19A4-4A9A-9C93-<u></u>AB9A4554D6CE@gmail.com</a><br></div>
<mailto:<a href="mailto:4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE@gmail.com" target="_blank">4FBFE344-19A4-4A9A-<u></u>9C93-AB9A4554D6CE@gmail.com</a>>>,<br>
Bill Wendling <<a href="mailto:isanbard@gmail.com" target="_blank">isanbard@gmail.com</a><div><div class="h5"><br>
<mailto:<a href="mailto:isanbard@gmail.com" target="_blank">isanbard@gmail.com</a>>> writes:<br>
<br>
Have you been sleeping poorly worried about the Clang 3.5<br>
release? Well,<br>
this may help! The plan right now is to start testing in<br>
July with August<br>
as the target release month. There isn't a schedule yet,<br>
of course. But it<br>
should be a goodly amount of time for all y'all to prepare<br>
for the release<br>
process.<br>
<br>
If you have any questions, please let me know. If you'd<br>
like to volunteer<br>
to be a tester, also let me know. :-)<br>
<br>
I have some packaging changes I'd like to see in place for the 3.5<br>
packaging. The changes include some more utilities in the<br>
package for<br>
refactoring tool developers and there is an issue with the way the<br>
Windows packages are being built that causes them to omit many<br>
of the<br>
things in the unix packages. Again, this is to make it easier to<br>
write refactoring tools.<br>
<br>
<br>
So far the idea with the Windows installer has been to provide a<br>
toolchain rather than a complete SDK, but it'd be nice to see if<br>
we can head in that direction, perhaps with a separate SDK package.<br>
<br>
CC'ing in Hans who has opinions on this.<br>
<br>
Which files did you want to include specifically?<br>
<br>
<br>
Initially I didn't want to do this because it bloats the installation. The package itself is compressed, so a lot of the code duplication is mitigated.<br>
<br>
Normally people solve this with shared libraries, and I assumed that's what we did on Linux, where we have a shared library build. Turns out I was wrong, our pre-built binaries are totally static. So maybe this doesn't matter as much as I thought it did.<br>
<br>
Relatedly, I think at some point we should add LLVM_EXPORT annotations to APIs in Support/ADT, IR, Target, etc,<br>
</div></div></blockquote>
<br>
<br>
I agree that it would be absolutely fantastic to support shared library / dll builds in the configuration you describe and think we should work towards that.<br>
<br>
I hope however that we _never_ attempt to do it with annotations like LLVM_EXPORT in the source core, nor with export lists. The reason:<br>
<br>
1) They're a complete pain to maintain for developers not working on Windows.<br></blockquote><div><br></div><div>I don't have a dog in this race either way, but I should point out that if you build with -fvisibility=hidden and let your annotation expand to __attribute__((visibility("default"))) while compiling your library and to nothing for clients of your library, non-Windows shared builds will work exactly when the the Windows shared build works. (This is how the Chromium components build works, and it works fairly well there as far as I can tell.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2) Even on Windows, there are at least two possible dynamic linking configurations:<br>
(a) several modular DLLs<br>
(b) LLVM.dll + clang.dll<br>
(c) LLVMClang.dll<br>
<br>
Annotations could only ever support one of the above given that what's exported and what's imported is different for each.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
so that we can reduce our .dynsym count and actually support an LLVM.dll on Windows.<br>
</blockquote>
<br></div>
So, it strikes me that this problem has great parallels with LTO, specifically the task of calculating the minimal set of symbols and interdependencies between modules (in this case shared libraries and executables).<br>
<br>
Perhaps we can treat this as a technology problem and hook into LTO or introduce some similar analysis to calculate shared library import / exports without having to pepper them throughout the source code.<br>
<br>
Rafael and I were discussing something like in person recently. Rafael, can you think of a way the LTO machinery could assist in determining DLL imports and exports at build time?<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
However, I know there is *strong* resistance in some camps due to the burden this would impose.<br>
</blockquote>
<br></div>
That resistance is valid. Annotations have been a total mess in the projects I've seen them applied. Apart from LLVM I'm sure other projects like WebKit / Chromium wanting to support DLL builds would benefit from any solution we come up with.<div class="">
<div class="h5"><br>
<br>
Alp.<br>
<br>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>