[Zlib-devel] Re: zlib-1.2.0.f-cos5 and cygwin

[Cosmin Truta]

On Wed, 22 Oct 2003, Charles Wilson wrote:

> Okay [...] I've just been taking care of it -- it
> originated from the franken.de cygwin "ports" list.

Thanks for taking care of it :)

> >  Furthermore, the test that rules out __CYGWIN__ isn't necessary,
> >  because Cygwin can benefit just as well from the
> >  __declspec(dllimport) and __declspec(dllexport), and the WINAPI
> >  stuff does not affect it as long as ZLIB_WINAPI is not defined
> >  (Cygwin users don't have any business with ZLIB_WINAPI anyway.)
>
> And the same ("Cygwin users don't have any business with...") holds true
> for __declspec() stuff.  We have decided to always use auto-import
> whenever possible.  That way, if I want to link an app statically to
> zlib I just DO it. ld -Bstatic (or gcc -static during link phase).  If I
> want to link dynamically I just DO it.  ld -Bdynamic or plain gcc during
> link phase.

I thought that __declspec(dllimport) adds a little extra performance at
compile time (it does with Microsoft C and Borland C). It isn't
necessary, and even with the other compilers we decided to leave it
disabled by default -- just because, as you say, there is no hassle when
switching between a static build and a dynamic build. But, if someone
wants a specialized build, and wants that little extra, then one can
enable ZLIB_DLL. And it's nice that a DLL built with ZLIB_DLL is
entirely compatible with a DLL built without ZLIB_DLL.

Last time I checked, it was the same in Cygwin, but Cygwin evolved a lot
since then, and I might have lost the track. Is the auto-import option a
compile-time option, or a link-time option? If it is a link-time option,
and its outcome is independent on the use or the misuse of
__declspec(dllimport), then I'm impressed.


> No need to set compiletime flags like -DBUILDING_DLL or -DLINKING_STATIC
> or whatnot, and compiling different .o's depending on (future) linktime
> decisions.  It's MUCH more unix-like this way.

Again, to clarify: NOW (in 1.2.0) it's the same everywhere, in all
Windows compilers. It didn't use to be up until 1.1.4, which was a
problem (which was one of the many problems that made us decide to
redesign the whole DLL interface and release it under a new name).
ZLIB_DLL is now disabled by default exactly for the reason you
mentioned: it sits in the way of a smooth static+dynamic build. Power
users can enable it, and we assume that power users know what they're
doing. In fact, it's properly documented in DLL_FAQ.txt

> (Really, there are four states here which requires two different #define
> binary flags minimum, at compile time, even if one of the four states is
> degenerate:
>    building dll -- you'd want __declspec(dllexport)
>    linking an app to the dll -- you'd want __declspec(dllimport)
>    building the static lib -- you want ""
>    linking an app to the static lib -- degenerate case, you want ""
>
> Blech.  Way too icky.  See
> http://www.neuro.gatech.edu/users/cwilson/cygutils/OBSOLETE/index.html


You're right it's yucky, but it isn't like this anymore. I tested the
newer zlib.dll with Cygwin -- which, I agree, wasn't the latest, and
the makefile was win32/Makefile.gcc, not the most appropriate, but
conceptually it's the same setting. I mixed the static and dynamic
builds (lib + apps) without any problem.

> > - Instead of using SHAREDLIB and SHAREDLIBV, which is confusing,
> >  you could use SHAREDLIB for the DLL (which is consistent with the
> >  use on Linux to represent .so) and IMPLIB for the import lib.
> >  This is what I did in "win32/Makefile.gcc".
>
> Oh, sure -- but this way the rules are (more-or-less) the same for both
> cygwin and for unix, and I didn't have to add a new variable that was
> unused on every other platform.  I actually did it "your" way first...

Okay.

> I'll wait for the "real" 1.2.0 and then I'll respin my patches,
> incorporating your suggestions.

It will be 1.2.1, following 1.2.0.7. The 1.2.0 version, which was
released a couple of months ago, will remain just a private version.
So you will wait for 1.2.1, and you'll send your patches for 1.2.2
[ not getting lost into these number may not be so easy, after all ;-) ]


Cheers,
Cosmin