Hi,
There are 4 ways to deal with the problem of exported variables when
building shared libraries on Woe32 platforms. Programmers of shared libraries
have to choose among them. Two of them I'd consider unacceptable for use
in serious projects, and among the remaining two ways one is hard to put
in place in projects that make use of gnulib.
The remaining way appears to be a good compromise between
- memory use and standards conformance - the resulting DLLs behave like
DLLs built with Microsoft's compiler,
- efficiency of the generated code - it does not have more indirections than
code compiled with -fPIC on ELF,
- amount of code changes - the only change to source code is that declarations
of exported variables in header files must be marked as DLL_VARIABLE; no
changes needed for functions,
- amount of configure / makefile infrastructure - only the DLL_VARIABLE macro
must be defined; its value can be determined in an autoconf macro and is
fixed throughout the compilation.
You find complete details about this approach in
http://www.haible.de/bruno/woe32dll.html
A prototype of this approach is being used in GNU libiconv-1.11 and
GNU gettext-0.15.
But currently, libtool lacks about 20 lines of code to make this approach
actually work.
I'd suggest to add this support to libtool. Details are in the above mentioned
web page.
I don't suggest to add it to the linker (GNU ld), because I heard rumours that
libtool shall in the long term also support the Microsoft compiler and linker
('cl'). Putting the support for this approach into libtool will also make it
work with 'cl', whereas putting it into GNU ld would not.
Bruno
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
