AW: improve support for building DLLs on cygwin and mingw

[Duft Markus]

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: address@hidden [mailto:address@hidden Im Auftrag von Bruno Haible
Gesendet: Montag, 4. September 2006 13:49
An: address@hidden
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