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

[William A. Rowe, Jr.]

Cosmin Truta wrote:
> On Mon, 1 May 2006, William A. Rowe, Jr. wrote:
> 
> But is the manifest necessary? 

Yes.

> 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)?

No.  Notice the use of if exist $@.manifest before we go to work.  For any
traditional compiler users, the manifest changes don't get triggered.

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

The Visual Studio 2005 ATL, MFC and even CRT ship as Win32 SxS assemblies.
This means that sitting in your \windows\winsxs tree are potentially different
Release/Debug * CPU Architecture flavors of the C Runtime.  The autogenerated
.manifest describes which blinkin CRT it was linked against.  So yes, they
are manditory unless you install a private copy of msvcr80.dll in your app's
directory, and it's much cleaner to do this mt injection of the .manifest
file contents into the .exe or .dll's resources than to tote it around
everywhere.

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

I may have another workaround, however -wd4996 is a reasonable bandaid to
permit folks who are downloading the free VisualStudio Express C++ edition
to be able to roll-their-own zlib.  Having more folks build their own
open source software is always a good thing.

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

+1 to that alternative to -wd4996 - I was deliberately avoiding any source file
pollution in this patch.  For the next release your suggestion is quite sound
and prefereable, actually.

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

Because some of us actually have to support the user who's app is
crashing, no matter what nice "no warrenty" clause is attached to
zlib's license ;-)

> and why are you slowing the DLL down in order to enable stack backtrace? 

Because I personally believe in sound stackframes, strongly object to
bastardizing the architecture to get at the last ounce of performance,
and because, programs crash :)

With zlib/openssl/httpd, in one case, I uncover nested bugs in one lib
that are apropos of nothing in those sources, it's garbage in-garbage out,
and need to get back to the source which sent up the garbage.  Not in
debug/development time, but in the real world.

> You can use the Visual C++ project in the "projects/" directory, and that 
> one creates everything you need, both for debug and release purposes.

No interest.  Sure it's useful in many respects, but not useful when
someone throws a user.dmp over the wall at me, and not when I'm putting
together an application (such as httpd).  Easier to do the three command
line config/make/make install or its local equivilant.

And you keep confusing the idea of creating a debuggable/traceable release
binary with turning on debug mode.  Debug mode is a fun little toy.  Until
you throw in /Ox you don't know how much stress you've put the code under.

Do you really think there's a single exe/dll on your box from Microsoft,
which Microsoft hasn't already archived in their .pdb vault?

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

Yes, and this means that anyone using the official dll can't be debugged
once they crash and burn.  Not cool, and the reason the Apache httpd project,
possibly one of zlib's widest consumers since mod_deflate's come into the
official distribution, will roll their own.

If you add ***at least*** the suggested /Zi, /Debug, /incremental:no changes,
then the .dll does not change.  Post the official zlib1.dll, but also post
for diehard developers supporting your zlib1.dll the corresponding zlib1.pdb.

If you add the /Oy-, you discover that the Dr. Watson file no longer dead
ends with lots of ???????? unknown origin functions, so the entire problem
can be troubleshot.  If you don't, at least dropping the official zlib1.pdb
alongside the official zlib1.dll will let Dr. Watson do the same.

If you are really looking at speed issues, why haven't you built -G5 given
that pentium today is a minimum baseline?  -G5 binaries still will run on
older CPU's (just less efficently).  However, another quirk, folks compiling
on VisualStudio 2005 will get -G5 deprecated warnings.  Another example of
where I couldn't care less, it's another warning that -WX ignores.

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

Thanks for the review.

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

Happy to help in about two weeks, once the landslide of work on all three
major httpd versions current maintenance releases is complete, and everything
I put off while in the process gets accomplished.

Whatever I can offer to defer any further motion twords am/ac/lt ;-)

Bill