[cfe-dev] [PATCH] plugin problem on Windows

[John Thompson]

 Ó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

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110405/e569a4e3/attachment.html>