Hi there! I implemented wgcc (a compiler wrapper behaving like gcc but calling cl.exe). Since the target should be to compile sources with minimum changes i have done lot's of work for this. The only thing one has to do with wgcc is:
Define a macro like MYPROG_EXPORT to __declspec(dllexport) when compiling the sources, and to __declspec(dllimport) when using the header file from the outside (this shouldn't be that hard ;o)) (gets even better in wgcc v2, one will not need to export anymore, just import ;o)). This works for shared, and (!!) for static libraries, since wgcc generates some symbols. This was one of the main problems, that any executeable sources can _never_ know which library gets linked statically or shared. Maybe you want to have a look at it, since its as far as i think a not too bad way of doing it... By the way wgcc is supported by libtool with the wgcc patch which can be found @ www.sourceforge.net/projects/interix-wgcc Cheers, Markus -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bruno Haible Gesendet: Montag, 4. September 2006 13:49 An: libtool@gnu.org Cc: Charles Wilson; Danny Smith; Filip Navara Betreff: improve support for building DLLs on cygwin and mingw 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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool