john.brawn added a comment. In http://reviews.llvm.org/D12903#251361, @rengolin wrote:
> In http://reviews.llvm.org/D12903#249406, @thakis wrote: > > > Also also, this approach fundamentally doesn't work on Windows. > > > I don't think it's supposed to, anyway. :) Actually, I think it can work on Windows. Certainly -fplugin=foo.dll works on windows and the dll is correctly loaded, but the problem is building a dll that does something useful. Currently there's no way to build clang/llvm on windows so that LLVM_ENABLE_PLUGINS is true - setting BUILD_SHARED_LIBS sets it to true, but BUILD_SHARED_LIBS doesn't work (lots of linker errors). However I've managed to hack up a build of clang not using BUILD_SHARED_LIBS where it's possible to build plugin dlls that work (by sprinkling __declspec(dllexport) all over the place), so it doesn't look like there's a fundamental problem here. Also maybe it's possible to use llvm-readobj on the intermediate .lib files to generate a list of symbols to export and put that in a .def file for the link step and not have to do any modification to the source files at all, though I haven't been able to get that to work. Anyway that's a bit of a digression. I've made naming change to OPT_fplugin_EQ, so I'll check that in. Repository: rL LLVM http://reviews.llvm.org/D12903 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
