Re: gettext cvs, woe32 dlls

[Charles Wilson]

Bruno Haible wrote:
> > A similar methodology could be adopted by other C libraries on those 
> > platforms.  I don't think a similar solution will work, in general, for 
> > C++ libraries
>
> Isn't a static class member field just the same thing as a data variable
> with different name mangling?

Probably, but that's not the whole issue.  When compiling the (static) 
C++ library itself, your technique would NOT label the class as 
declspec(dllexport).  It would not be labeled at all. (When compiling 
the client, your technique would label the class declspec(dllimport).)

So, when compiling the static C++ library, you have to (manually? 
semi-automatically using a script or recipe?) create the _imp__* 
pointers that will be used by the clients (who will see a 
declspec(dllimport) decoration and will thus *expect* the _imp__* to be 
present).

This will include _imp__* pointers for actual static class member 
fields, as well as other hidden class attributes (and that's where 
things get hairy).  Perhaps vtables and type_info -- but maybe other 
"hidden" implementation details (what are those "guard" variables, 
anyway?).  Then there are the class attibutes of template 
specializations, as well as those of specialized template instantiations 
(which are not the same thing)?  You'd have to figure out the mangled 
names of all of the hidden and obvious class attributes, and (manually?) 
create the _imp__* pointers for them.

member functions (virtual or not) will all be handled by auto-export 
when building the library, so that's no problem.  I'm not sure what 
steps need to be taken if any to handle instance data.  And don't even 
think about member template instantiations...

This gets really ugly, really fast.  Pretty soon, you're going to have 
to have a tool to do this for you -- but we already have one, that 
(supposedly) understands all these rules and intricacies.  It's the c++ 
compiler itself (or at least its front-end component) -- but now you're 
back to needing declspec(dllexport).

And that's why I think your solution won't work *in general* for C++.

Although, it would probably be okay to do this: (1) when BUILDING_LIB, 
always declspec(dllexport). (2) when !BUILDING_LIB, always 
declspec(dllimport).  Basically, the same .o's go into both the DLL and 
the .a -- the only difference being static initialization is handed by 
DLLMain() in one case, but by the exe's pre-main startup code in the 
latter case.

(There is one difficulty, tho, having to do with the design of C++ 
libraries in general -- sometimes they just *work differently* if built 
static or dynamic -- the C++ language lawyers run away from the problem 
by simply stating that the mechanics of dynamic libraries are inherently 
platform dependent and are therefore not covered by the C++ standard. 
But that's not a problem with your idea above, per se -- it's just an 
ancillary issue that impacts upon it.   Anyway, here's a for instance: 
if my_app doesn't reference an object whose class contains a static 
initialization, then that class's code is not linked in to my_app -- so 
this mystery class's static initialization doesn't happen.  In the DLL 
case it does happen.  This could be important if I'm relying on a side 
effect of that static initialization --- like, for instance, 
automatically registering a concrete component type with an abstract 
factory)

> > Q: what about the installed files in /usr/share/gettext/ ?  If 
> > <libintl.h>/"gettext.h" is "munged" on cygwin, then can cygwin's 
> > gettextize make an un-munged client source package -- so that the 
> > "munging" occurs when the client package gets built?
>
> No problem: gettextize and autopoint take their files from $prefix/share/,
> not from $prefix/include/.

Okay, thanks for clearing that up.

--
Chuck