<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 3:53 AM Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Feb 28, 2016 at 9:21 AM NAKAMURA Takumi via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: chapuni<br>
Date: Sun Feb 28 11:17:00 2016<br>
New Revision: 262188<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=262188&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=262188&view=rev</a><br>
Log:<br>
[PM] Appease mingw32's auto-import DLL build with minimal tweaks, with fix for clang.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>As I mentioned to you in IRC, I really dislike this change.</div><div><br></div><div>I think this needs discussion and at least some substantial changes in the way of comments to explain what is going on and why it is needed.</div></div></div></blockquote><div><br></div><div>Sorry. I supposed I can tweak this issue since I saw your r262127 and r262128, that I supposed you tried to appease this issue.</div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>If we needed to get your bot working again, I would frankly have been happier to just revert my patch. But now we have to live with this patch instead because the merge conflicts at this point will be a nightmare.<br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><div>So, can you please try to walk everyone through what the requirement is here? Your commit log does not contain a lot of details... My best guess based on the nature of your change is that mingw32 has a DLL building mode which is buggy because it doesn't produce a strong definition of the static object in the base class the derived class is defined.</div></div></div></blockquote><div><br></div><div>It's also nightmare to me.</div><div><br></div><div>I think it is a limitation in Win32 DLL model, or mingw's binutils-ld.<br></div><div><br></div><div>For example T::PassID (instantiated with <T>), there is just but a symbol to T::PassID, not the section of T::PassID, in the DLL image.</div><div>To link each section (and symbol) of T::PassID with the DLL that has T::PassID, binutils-ld doesn't treat that T::PassID is defined. Just emit the instance of T::PassID to ignore the DLL.</div><div><br></div><div>AFAIK, it was just the way that T::PassID (or its instantiated class) declared as extern.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>If that is the case, I am really concerned about continuing to support this configuration with LLVM. We have had numerous, painful problems supporting mingw in the past, and this seems like it is handcuffing us unreasonably.</div></div></div></blockquote><div><br></div><div>Cygming's BUILD_SHARED_LIBS=ON has a couple of good points;</div><div><br></div><div>1) Detect and keep more strict libdeps, than other shared object models.</div><div>2) Keep supporting C++ plugins on Win32.</div><div><br></div><div>I wish I could keep such a configuration. That said, your changes are also straightforward and fine.</div><div>I will seek any other better way.</div><div>I don't have strong opinion whether to revert yours or to track and fix declarations, or abandon BUILD_SHARED_LIBS.dll.</div><div><br></div><div>Regarding to (2), I don't recommend to resolve to tweak build scripts. I don't want 3rd party to use special tools to create plugin.dll, but our header files.</div><div><br></div><div>Do you remember what were "numerous, painful problems supporting mingw"?</div><div>AFAIK, the issue, explicit instantiation of objects, is the just one, and others may be generic to Win32.</div><div>I did tweaks around plugin support in llvm, clang, and clang-tools. I don't think they were painful.</div><div>  </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>And if I understand correctly, mingw32 works just fine when not using a particular DLL configuration?</div></div></div></blockquote><div> </div><div>Yes. I am certain that supporting mingw32 should be more straightforward than MS SDK.</div><div>Mingw32 is just "Win32 development environment with gnu toolchain".</div></div></div>