<div dir="ltr">I'm about to switch over the the conclusion here since I've already gotten this wrong a few times. =[<div><br></div><div>However, I want to say for the record that I don't really think we should keep supporting this kind of DLL builds given the limitations of DLLs when it comes to correctly implementing these aspects of C++. I suspect we should really move toward having an LLVM.dll (and a LTO.dll, etc) and only using static linking within that on Windows. (I know that actually producing an LLVM.dll is a huge challenge currently due to CMake and other issues.) Trying to support the fully shared build with the limitations of DLLs when it only even somewhat works on one platform (mingw32, as other things prevent it from working w/ MSVC from my understanding of conversations with Reid) seems like a losing battle and to have a high cost for very little gain for the community.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 1, 2016 at 11:09 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 1, 2016 at 1:32 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<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>I don't disagree with your analysis, but I'd like to get a build bot that tests DLL builds with a host toolchain other than mingw32 if this is in fact common to those configs (as no other bot broke that i saw)... But that's a separate issue.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We don't support BUILD_SHARED_LIBS=ON with MSVC. It doesn't come with tools that make it easy to support this configuration. CMake recently added some support for building DLLs that export all symbols, but it's very new and requires you to annotate all your exported global data, i.e. pass ids.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>The base class isn't *just* providing the static variable. It is also providing the accessor method. I really like using a method instead of raw access to the static data member. It is also providing the name of the pass. So what we'd likely end up with is still having the base class but having a friend declaration and private static data member in the derived class.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sure, that'd work.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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>But before going there, I'd like to ask if there is another approach that would work: do you see any ways to effectively cause the static data member to be emitted reliably?</div></div></div>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><br></div><div class="gmail_extra">I'm sure we could come up with a way to get the ID emitted reliably at the definition of the analysis, but we also need to ensure that the ID is unique, which means we need something like the extern template declaration in the header.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think your idea of using CRTP to stamp out the pass name and ID accessor is reasonable, and then we can use a normal C++ declaration/definition pair in the derived class for the ID.</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>