Hi John, The other day I ran across a post by Matthew of the Polly team and it seems that the Polly team might have made some progress regarding plug-in support on Windows. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130311/168147.html
Although I do not fully understand their implementation, it sounds like the Polly team was not trying to add __declspec(dllimport/dllexport) all over the clang/llvm source base. They used a .def file to export the necessary symbols from the clang executable, and then they just tried to use the imported symbols without __declspec(dllimport). According to the MSDN blog entry below, dllimport is not necessary for function calls and is only necessary for data access. I am cc'ing Matthew in case I misunderstood Polly's implementation. http://blogs.msdn.com/b/russellk/archive/2005/03/20/399465.aspx?wa=wsignin1.0 I think both the Cygwin and the mingw environments on Windows provide a dlltool executable that can automate the generation of .def files from either the object files or a static library. I am not aware of equivalent tools in the Visual Studio package; you may have to write some scripts to extract and package the symbols if you are using Visual Studio. HTH, - Gao From: [email protected] [mailto:[email protected]] On Behalf Of Thompson, John Sent: Friday, March 15, 2013 6:04 PM To: [email protected] Subject: RE: [PATCH] Implement a sane plugin API for clang 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. 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. Has anyone else worked on resolving the plugin issues for Windows or the Clang-libraries-as-DLLs build? -John
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
