On Sun, 04 Jan 2004 19:54:55 +0100, Mariano Alvarez Fernandez malfer@telefonica.net wrote:

...

BTW, what about the mingw win32 .DLL support?

Well, my opinion about DDL for a small and unknow lib like GRX is negative. [...]

My opinion on the windows .DLL-s as such is negative, they are a piece of wrapping crap (see mingw/doc/a2dll).

Anyway if only changes to makefiles were necesary (like the linux ones) I will add it, but I found the patch very invasive.

Gee. The main problem is these DATA symbols, which must be declared with __declspec(dllimport) if referenced from an apppication. An unglier but less intrusive way to handle these may be to declare all exported data symbols as macros to functions() which return the actual symbol values (oh mine!), something like:

foo.h: #ifndef __DLL32__ extern type data; /* as usual */ #else extern type _data(void); #define data _data() #endif

foo.c: #ifndef __DLL32__ type data; /* as usual */ #else #undef data static type data; type _data() { return data; } #endif

I say less intrusive because (1) only the headers/sources (internal to GRX) which declare/define exported data will be affected, (2) the GRX sources will be free to include internal or public headers (as before), and (3) 'extern' will not need to be declared at neither internal nor public level. We already have plenty of function-to-data macros (unless GRX_SKIP_INLINES if defined), so having data-to-function ones won't make such a big diff IMHO.

It's ugly I must admit, but considering how the windows .DLL-s work, the 'DATA' specification probably does something similarily ugly - only invisible.

a time every year someone ask for a GRX DLL, so I will put the patch in the more things page in the GRX site if you no oposite it.

The above needs some work, and I'm not sure the resulting library will run properly, so I'll only try if it seems good enough to you to be included in GRX. If not, placing the current patch under 'more things' is OK to me. RFC.