Re: gettext cvs, woe32 dlls

[Bruno Haible]

Hello Charles,

Partial response:

> I believe it will work for gettext on cygwin and mingw.

I believe that too; I'm currently testing it.

> 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?

> I saw the ChangeLog comments 
> concerning some of the files my patch modified: "Reimported from 
> gnulib".  I could just imagine a new re-import clobbering my changes...

The gettext copies of those files still differ from the gnulib originals,
as long as I haven't submitted a nice packaging for DLL_VARIABLE. But a
nice packaging for LIBFOO_DLL_VARIABLE - one per library - would be
impossible.

> >      sed -e 's/export \([^()]*\);/export __declspec(dllimport) \1;/'

> Nice.  I like it.  (I assume that on other platforms, the 'export' 
> prefix is simply removed?)

It should read 'extern', not 'export'. Sorry.

> 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/.

Bruno