[PATCH] D16760: Add support for importing and exporting Registry objects on Windows
Reid Kleckner via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 2 14:22:13 PST 2016
rnk added a comment.
In http://reviews.llvm.org/D16760#342060, @ehsan wrote:
> Importing symbols on Windows is a hopeless effort. We'd either need to spray everything in clang with a CLANG_API macro that resolves to dllimport/dllexport depending on what you're building, or maintain a .def file with mangled names of everything we export, both of which are terrible solutions IMO. This setup is intended to be used with static linking:
CMake has some new auto-export functionality that I want to look into at some point. It didn't work immediately out of the box, so I had to put it aside for now, but eventually, I would like to stop statically linking clang.exe.
Comment at: include/llvm/Support/Registry.h:172
@@ +171,3 @@
+ REGISTRY_CLASS::import(DL, #REGISTRY_CLASS)
> rnk wrote:
> > Do you think we should have an #else block here that defines these macros to nothing on Unix, so that clients don't have to do the platform ifdefs?
> That sounds like a good idea. (FWIW I'm really unhappy that we needed to change the client side API for this, but sadly there is no way to avoid that.)
What if we kept the export side (the non-client side) the same and changed the Registry constructor to do dynamic lookup in all loaded DLLs for the exported symbol? Then we'd only have to change clang and opt.
More information about the llvm-commits