<div>
<p>>Can't you weak-link the clang libs to your plugin? That's how it's done on OS X I think.</p></div>
<div>Sorry, I don't know what that means in the context of Windows.  It appears that on Windows, the Clang libraries are all statically linked.  Perhaps if the Clang libraries were DLLs, it might work, assuming the DLLs would share the data space as well as the code.  I tried re-building with cmake using -DBUILD_SHARED_LIBS=ON, but go lots of errors, and the cmake.html page indicated it didn't work.<br>
<br></div>
<div class="gmail_quote">On Fri, Feb 11, 2011 at 1:39 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<p>Can't you weak-link the clang libs to your plugin? That's how it's done on OS X I think.</p>
<p>Nico</p>
<p>(phone)</p>
<div>
<div></div>
<div class="h5">
<div class="gmail_quote">On Feb 11, 2011 1:18 PM, "John Thompson" <<a href="mailto:john.thompson.jtsoftware@gmail.com" target="_blank">john.thompson.jtsoftware@gmail.com</a>> wrote:<br type="attribution">
> 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>> One way to fix it is to have the plug-ins provide a function hook for<br>> retrieving the node. Since the address look-up function in Clang looks in<br>> all plug-ins loaded, that means it has to be a uniquely-named function.<br>
> Therefore, perhaps basing it on the plug-in name is a way to go,<br>> <br>> I've enclosed a patch that modifies things to do this. It expects the<br>> plug-in to export a function with a name like "Get_(plug-in name)_Node that<br>
> returns the node instance. See the modified PrintFunctionNames for an<br>> example of this. Since the name for the PrintFunctionNames plug-in is<br>> "print-fns", I have the function lookup code replace '-' with '_' to get a<br>
> legal C name.<br>> <br>> I've also modified the example.CMakeLists.txt file to build the example<br>> projects as part of the main build.<br>> <br>> I also needed some changes in the Registry class to add an AddNode function<br>
> and expose some privates so the plug-in can get at its node.<br>> <br>> I've enclosed two patch files, one for the Clang side and one for the LLVM<br>> side (the Registry hack).<br>> <br>> Permission to check it in? Otherwise, please suggest an alternate fix.<br>
> <br>> -John<br>> <br>> -- <br>> John Thompson<br>> <a href="mailto:John.Thompson.JTSoftware@gmail.com" target="_blank">John.Thompson.JTSoftware@gmail.com</a><br></div></div></div></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>