Óscar,
It is -DBUILD_SHARED_LIBS=ON, not -D SHARED_LIBRARY=true.
Oh sorry, I was typing from memory. But that was one of the iterations I tried, and just now retried, with the same hang. So you are not seeing the hang when trying to build any of the generated projects?
BTW, we could really use some extension to the documentation for the options available in the cmake stuff.
Michael,
It’s actually possible to do this without explicit directives by
making use of link -dump to dump the symbol table to an export file
and relink all the static libs into a giant DLL that exports
everything. At one point I was working on this, but got pulled into
other things.
I don’t see a -dump option for the Visual Studio 2008 linker in the docs. Did you mean the /MAP option?
Do you have a way to automate the exporting? I’d like to find out more.
Óscar,
What’s the difference among indexed and non-indexed exports? The exports
file I created was just a list of symbols and the linker failed
complaining about the 2^16 limit. Then I read some documents on msdn and
the 2^16 limit was mentioned, but nothing about 2^32.
By “indexed” I assume you mean “ordinal”.
My understanding is that the exported symbols can be referenced by ordinal or name, the ordinal being a carry-over from the old days for saving space. Looking at the .def file docs, I see that under the “EXPORTS” section you can do either:
ExportNameA @1
ExportNameB
where the first line is for an ordinal export, and the second is a named export. I’m wondering if the same limit applies to the named exports. I would gues not.
In the past, I’ve always just used the __declspec(export) and __declspec(import) directives in the headers for DLLs. Basically you put something like the following in a main header for the library, for example, for MyLibrary:
#if defined(DLL)
#if defined(MYLIBRARY_EXPORTS) || defined(BIG_DLL_EXPORTS)
#define MYLIBRARY_LINKAGE __declspec(dllexport)
#else // client sees this
#define MYLIBRARY_LINKAGE __declspec(dllimport)
#endif
#else // assume static library linkage
#define MYLIBRARY_LINKAGE
#endif
You define MYLIBRARY_EXPORTS in the project file for the library (or BIG_DLL_EXPORTS for a single big DLL), and then you use the linkage symbol in the class or function declarations that should be exported, i.e.:
class MYLIBRARY_LINKAGE MyClass
{
// All class functions will be exported.
};
MYLIBRARY_LINKAGE void MyFunction();
I’d be willing to take on this task, if this is the way we want to handle it. If we can’t automate the .def file creation, this would probably be the better option.
But I would like to hear of other ways too.
It seems trying to get Clang as individual DLLs probably wouldn’t work. Creating a big CMake file that builds all the sources into a single DLL would probably be a pain to maintain. Perhaps a CMake file that turns on the __declspec directives in the static libraries but still using he current CMake files, and then builds the DLL from the static libraries is the way to go.
Or, instead of using __declspec, have the individual static libary builds output a .map file, and use a custom tool that pulls out the exports and creates a .def file. (Was that what you we working on, Michael?) It seems like there ought to be an option for just exporting all globals.
Argyrios,
I think we should move away from the llvm::Registry mechanism. How about the exported function returns a PluginASTAction*, we store all PluginASTAction* pointers that the plugins return and iterate over them when invoking plugin actions.
Sounds good to me. But if not, at least fix the Registry mechanism by adding the needed accessors, which curiously it doesn’t have, which is what I tried to do in my patch.
-John