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

[Charles Wilson]

Cosmin Truta wrote:
> Thanks for the patches. I am forwarding them to the zlib-devel list.
> Since we are now in a release candidate stage, waiting for 1.2.1 to
> come, maybe these patches will have to wait until 1.2.2. Let's see
> what Marks says about them.

That's fine.  I'm in no hurry.

> I have the following comments:
> 
> - The patch to "zconf.in.h" is not necessary. STDC is defined under
>  __GNUC__, so it doesn't have to be tested under __CYGWIN__.

Okay.  I was just doing a straight port of the 1.1.4 patches, taking 
advantage of new compiler features.  Truth be told, zlib was the first 
package I provided to the cygwin community about five years ago -- and 
the actual port (insofar as it relates to some of the code changes) did 
not originate with me.  I've just been taking care of it -- it 
originated from the franken.de cygwin "ports" list.

So, this part can go away; doesn't bother me.

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

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.

(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

I used to do it that way...before auto-import.  (Naturally this decision 
is not applicable to mingw, where the utmost priority is compatibility 
with MSVC -- which doesn't do auto-import).

> - The addition of -O3 to the Cygwin-specific CFLAGS in "configure",
>  isn't necessary. It's turned on by default in line 67, if gcc is
>  detected, and, in fact, it might not even be a good thing after all.
>  Our latest testing showed that -O3 does not make a faster zlib,
>  but in fact, it makes it arguably and hardly-noticeable slower.
>  So -O3 isn't any good.

Again, a carry-over from the original franken.de stuff.  No big whup; it 
can go away.

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

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

> The answer to your question at the end is yes. Notwithstanding the
> ZLIB_WINAPI issue (which isn't affecting Cygwin), zlib-1.2.x is
> intended to be fully binary compatible with zlib-1.1.4; and if it
> isn't, that's a bug.

Ah, good to know.  That'll make my life a little simpler.

--
Chuck