[Zlib-devel] zlib-1.2.5 DLL build

[Cosmin Truta]

On Mon, Jul 12, 2010 at 4:29 AM, Vincent Torri wrote:
>
> On Mon, 12 Jul 2010, Cosmin Truta wrote:
>
>> I have (finally...) built the zlib-1.2.5 DLL [...]
>> http://cosmin.users.sourceforge.net/testing/zlib125-dll.zip
>
> Which flags did you use to compile it, please ?

Nothing out of the ordinary:
make -f win32/Makefile.gcc

The specific versions of the compiler and libraries involved are
listed in the Build Info section in the accompanying README.txt:
Compiler: gcc-4.5.0-1-mingw32
Library: mingwrt-3.17, w32api-3.14


On Mon, Jul 12, 2010 at 6:41 AM, Jan Nijtmans wrote:
> Didn't do any tests yet, but just noticing that the sizes of zdll.lib
> and zlib1.dll differ quite a lot compared with the previous version (1.2.4):
>
>                 1.2.4               1.2.5
> zdll.lib        13438             38996
> zlib1.dll       77876           101376
>
> So, before making such a step, I would like to hear at least an
> explanation for this size difference. How does VC++ 6.0 do here?

You asked a very good question. I can't speak for version 1.2.4, but I
can tell you my recollection about 1.2.3, which IIRC was compiled
using VC++7.0 and linked to the VC++6.0 run-time library. And
zlib1.dll version 1.2.3 was also very small: 59904 bytes.

MinGW-compiled programs are usually expected to be more fat because
MinGW adds standard C compliant wrappers and security fixes around
MSVCRT.DLL. They're statically linked in the executable.

In zlib, in particular, the use of snprintf and vnprintf causes the
inclusion of the entire MinGW-supplied snprintf implementation.
MSVCRT.DLL has _snprintf, which does just have a pre-C99 name: it also
has a pre-C99 behavior, which is neither secure nor std-compliant.
That is the primary reason why MinGW-compiled executables tend to be
more fat. (More secure, too!)

If you wish, you can go back to slim by using _vsnprintf instead of
vsnprintf, not just for VC++, but also for MinGW. Then you have to
fiddle with the makefile to avoid linking of libmingwex.a. However, a
non-compliant and insecure _vsnprintf means a non-compliant and
insecure gzprintf. You'll save somewhere around 20-30k. But is it
worth paying the price?


On Mon, Jul 12, 2010 at 7:50 AM, Gilles Vollant wrote:
> some probably include C standard library as static, other uses DLL

As I explained above, it largely links to MSVCRT.DLL except for a few
portions in which a static mini-library is linked.

> VC++ 6.0 code is slow compared to VS2010 with all optimisation (including
> profile optilisation=

True. Not only the output of newer MinGW is increasing in size; the
output of newer VC++ increases, too. In my very brief experience, I
noticed the output size increases even more substantially with newer
VC++.

> I prefer a bigger DLL which is faster

Bigger doesn't necessarily mean faster. Last time I checked VC++2005,
it was producing large executables regardless the optimization level.
It just put more junk in the output. (... and so does MinGW.) But
overall, I think the increase in output size, at least with MinGW, is
not that bad. And you can hack away some of the cruft from the
executable, if you really want to, and have the need and the time to
do it.


On Mon, Jul 12, 2010 at 8:37 AM, Vincent Torri wrote:
> Well, that depends on the purpose of the use of the lib. On embedded
> devices, maybe a smaller lib is better for some people. That's also why I
> asked the compilation flags used to built the DLL.
>
> My POV is, even on embedded, i prefer speed, hence bigger size.

I agree with Vincent as well. In general, on embedded you want
responsiveness under a low-powered CPU. You want to save battery, and
not so much filesize (except in peculiarly constrained conditions, in
which case a general-purpose zlib probably isn't that useful) so you
want the executable code to be as efficient as possible.

In my opinion, 101KB is a decently small size for a DLL, although, of
course, I wouldn't say no to a trick that decreases that size without
compromising speed or compliance.


Speaking of speed: I didn't follow the ASM-related discussions lately.
Is contrib/inflate86 up to date? Is contrib/asm686 just for 686, or is
it good for generic x86? Do they provide any sizable increase in
execution speed?
Should I build a DLL that uses them?


Best regards,
Cosmin