[Zlib-devel] [PATCH] 1.2.3 makefile.msc usability & rc fix (too late)

[Cosmin Truta]

On Mon, 1 May 2006, William A. Rowe, Jr. wrote:

> I've closed the issue of .manifests, generated .pdb debugging for
> release zlib1.dll binary and corrected the .rc (you left it 1,2,2,0 in
> the last release)

You're right about 1,2,2,0 -> 1,2,3,0.

But is the manifest necessary? Does it not cause the build to fail on
vc6 (which, by the way, appears to be most popular among programmers who
are not interested in .Net)? I don't know much about manifest files. I
barely know they're good for executables on WinXP when it comes to what
GUI common controls are being used, and that's about it.

> http://www.apache.org/dist/httpd/binaries/win32/patches_applied/zlib-1.2.3-vc32-2005-rcver.patch
>
> I'd love for this patch to be considered.  It's a wee bit noisy
> (spewing various warnings that -wd4996 isn't known to the oldest vc
> 5/6 compilers) but with no ill side effects. That flag shuts down all
> the obnoxious VisualStudio 2005 noise about posix api's "deprecated"
> for ISO/C++ api's (utter bullshit).

That's not a good solution. You are essentially introducing obnoxious
noise in the output of compliant compilers (VC7 and earlier) in order to
shut up obnoxious noise in the output of a non-compliant compiler (VC8).

The right way to do it is by inserting the following lines in zconf.h.
[NOT TESTED!]

--- zconf.h~    Sat May 28 03:40:35 2005
+++ zconf.h     Mon May 01 16:20:00 2006
@@ -130,6 +130,18 @@
 #  define NO_DUMMY_DECL
 #endif

+/* Tell Microsoft Visual C++ 2005 to leave us alone and
+ * let us use standard C functions the way we're supposed to.
+ */
+#if defined(_MSC_VER) && (_MSC_VER >= 1400)
+#  ifndef _CRT_SECURE_NO_DEPRECATE
+#    define _CRT_SECURE_NO_DEPRECATE
+#  endif
+#  ifndef _CRT_NONSTDC_NO_DEPRECATE
+#    define _CRT_NONSTDC_NO_DEPRECATE
+#  endif
+#endif
+
 /* Maximum value for memLevel in deflateInit2 */
 #ifndef MAX_MEM_LEVEL
 #  ifdef MAXSEG_64K


> Generating the zlib1.pdb file does *not* affect the zlib1.dll in any
> way (although the /debug flags lead people to believe it does.)  All
> of the magic is entirely contained in the zlib1.pdb, with the
> exception of a reference to this file from zlib1.dll.  It's still just
> as optimized and efficient.  The /Oy- makes stack backtraces without
> the .pdb file possible to follow, that does slow things down just a
> bit.

But why do you generate .pdb files, and why are you slowing the DLL down
in order to enable stack backtrace? You can use the Visual C++ project
in the "projects/" directory, and that one creates everything you need,
both for debug and release purposes. "win32/makefile.msc" is solely
intended to produce the DLL that's going to be distributed. It's not
intended to provide debugging services of any sort. The VC6 project is
better suited for that, and does a much better job than the makefile,
too.

> I've attached my zlib123-solaris patch to clean up zlib compilation
> under solaris sunstudio cc, and emit some helpful noise when dynamic
> library generation is refused.  This is just a reminder of my earlier
> post.

That one looks okay.


BTW, I promised some time ago that I will look over the Unix makefile
and make it build both the static and the shared lib at the same time.
Sorry I didn't get to that yet, but I haven't forgotten either.


Cheers,
Cosmin