[Zlib-devel] 1.2.5 DLL broken?

[Cosmin Truta]

On Sun, Jun 19, 2011 at 1:24 PM, Mark Adler <madler at madler.net> wrote:
> Can the DLL meisters comment on this?  The zlib1.dll is the one provided by Cosmin on Aug 6, 2010.

I sent an email in which I was pointing to a new zlib DLL bundle (with
the same DLL, but a corrected implib) on Aug 5, 2010. It's called
zlib125-dll-patch1.zip, and I recommended distributing this one,
instead of the old one.

Mark, you might had missed that email? Here it is.


---------- Forwarded message ----------
From: Cosmin Truta
Date: Thu, Aug 5, 2010 at 1:50 AM
Subject: DLL build for zlib-1.2.5, patch 1
To: zlib-devel


Dear zlibbers,

zlib125-dll-patch1.zip is available at
http://cosmin.users.sourceforge.net/testing/zlib125-dll-patch1.zip

Mark, you may release it, and feel free to give it a better name, if
this one isn't self-descriptive or imaginative enough.

It's the same old package, to which I added Gilles' VS2010-built implib.
The modifications are mentioned in the README file.

Many thanks to John Bowler for testing, and also for his thorough analysis.

> I used Cygwin ar to examine the contents of both libraries.  The MinGW one
> contains a series of COFF object modules, apparently one for each entry
> point.  The Microsoft one contains three COFF modules at the start, however
> the remainder are simply chunks of data.  These files are all about 40 bytes
> long and consist of 20 bytes of numbers followed by the null terminated name
> of the entry point followed by the null terminated name of the DLL
> (zlib1.dll).  Presumably that data is understood by the Microsoft linker.

Yes, the data is understood by the Microsoft linker... Sigh...
I thought MinGW can be a one-stop shop that'll do what's needed, and
we won't need anymore the awkward two-tool combination that we used to
use around zlib-1.2.3. It seems we need another, even more awkward
two-tool combination now.

Best regards,
Cosmin