Re: AW: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Hello,

Markus Duft wrote:
> 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.

That's certainly a good idea. I would consider such a tool usable only
if it had no arbitrary limits, such as a maximum size of 65000 bytes for
an exports list, or similar. (I saw an MSVC error message once
"Too many variables in function" for a function with more than 1024 local
variables, and don't want to repeat such an experience.)

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

Very nice. "Just import" is also the point of the proposed libtool changes.
If everyone was using either GNU ld or your wgcc, one could consider
implementing this functionality in GNU ld. But there are people who
use MSVC direcly or using other wrappers.

> This was one of the main problems, that any executeable sources can
> _never_ know which library gets linked statically or shared.       

Yes, I agree that adding the extra export symbols not at DLL construction
time but also at .EXE construction time is even better. It allows not
only to use the same macro
  #define DLL_VARIABLE __declspec(dllimport)
for all sources that end up in shared libraries but also for any source
code, regardless whether it ends up being built shared or statically.

> Maybe you want to have a look at it

Where are the sources to your wgcc2 ? The source of wgcc1 doesn't appear to
generate exports as needed.

Bruno