On Fri, Mar 15, 2013 at 9:03 PM, Thompson, John < [email protected]> wrote:
> Hi Sean,**** > > ** ** > > I missed the discussion, but I saw your message and wanted to find out > where things stood on the plug-in API with respect to Windows. > I'm probably not the most informed about windows things, but I don't recall seeing any movement on this front, unfortunately. > **** > > ** ** > > A year or two ago I wrote a plug-in for Clang for generating LUA bindings, > and developing on Windows, found that the plug-in mechanism didn’t work on > Windows, because it relies on how *nix systems do DLLs. Unfortunately, in > Windows land, a plug-in DLL would have to be linked with Clang libraries > which are DLLs, and apparently building the Clang libraries as DLLs is > problematic, due to the build system and the messy business of > importing/exporting symbols.**** > > ** ** > > I managed to skirt the issue by still building the plug-in against the > static libraries, and hacking clang to look up call an entry point function > with a name based on the plug-in name so it could hook up the objects in > the plug-in. This, of course, was kind of dangerous, because the plugin > module and the clang executable would have totally separate static data > areas, not to mention the duplicated code segments.**** > > ** ** > > Then I did some work on making a big Clang DLL, to skirt some of the DLL > import/export issues, just exporting the symbol references needed between > the driver and the library, using some header conventions for handling the > exports. I intended to pursue this further, and try to resolve the clang > DLL build issues, but haven’t been able to get back to it. > Ouch, that's quite an adventure! -- Sean Silva
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
