<div>Yeah, I tried building a DLL version of Clang using:</div>
<div> </div>
<div>cmake -G "Visual Studio 9 2008" -D SHARED_LIBRARY=true .<br></div>
<div>but Visual Studio 2008 would just hang.</div>
<div> </div>
<div>I'm guessing it probably has to do with circular dependencies, which can be problematic on Windows with DLLs.  But even if it isn't, having Clang be a bunch of DLLs probably is not a good idea anyway.  Rather than try to figure it out, maybe the cmake build should be redone to directly build a single big DLL.  Since I don't know cmake (yet), I'll leave this for your comments.</div>

<div> </div>
<div>Since I was able to get a plug-in working with Clang not in a DLL, but not without a change to the basic mechanism, would this be a reasonable solution?</div>
<div> </div>
<div>Basically, rather than have the plug-in initiate a call to clang, the plug-in exports a function that Clang calls to get the needed registration information.</div>
<div> </div>
<div>However, this implies some restrictions on the plug-ins, which I don't know are acceptible.  One is that the plug-in can't directly access global functions or data in the Clang side; it all has to be through the object tree passed to the plug-in. This also means that virtual functions in the object will run in the context of the Clang side, and non-virtual functions will come from the plug-in side.  Another restriction is that you can't mix memory allocations, i.e. allocate a block from one runtime that is freed by the other.  I didn't seem to run into any of these in the Lua bindings plug-in I did, since it's purely an output mechanism.</div>

<div class="gmail_quote"> </div>
<div class="gmail_quote">Therefore, which should we do, fixing Clang as a single DLL, or the non-DLL scheme I used?</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">-John</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">On Sun, Feb 13, 2011 at 8:00 PM, Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es">ofv@wanadoo.es</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">John Thompson<br><<a href="mailto:john.thompson.jtsoftware@gmail.com">john.thompson.jtsoftware@gmail.com</a>><br></div>writes:<br>
<div class="im"><br>> With reference to the Bugzilla 9078 issue I posted, it appears the plug-in<br>> mechanism doesn't work on Windows.<br>><br>> To recap, in loading a Windows plug-in DLL, the DLL will have it's own copy<br>
> of the clang library code and data, such that the plug-in registry node list<br>> ends up in the DLL and not the Clang executable's data space, hence as-is,<br>> the plug-ins node doesn't end up in the registry instance in Clang.<br>
<br></div>A Windows DLL has a single copy of its code and data for a given<br>process. But I guess that the problem is that Clang is statically linked<br>into every plugin. A proper solution for that is to build Clang as a<br>
DLL. You can manually do that on MinGW, but not on VC++.<br>
<div class="im"><br>> I've also modified the example.CMakeLists.txt file to build the example<br>> projects as part of the main build.<br><br></div>The `examples' directory is optionally added from the toplevel<br>
CMakeLists.txt file. No need to add it again.<br><br>[snip]<br><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br>