Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics

Nobody in particular
kmx [...]

(no value)
Broken in:
(no value)
Fixed in:
(no value)


Subject: Ext-lib: Zlib support - change proposal
Hi, this is another post regarding external binary libraries included in strawberry distribution. Why do I want to discuss ZLIB? The main reason is this: despite the fact that ZLIB is already included in strawberry it is not possible to use the most common linker option -lz to link against it and most of the makefiles end up under strawberry with undetected zlib. What is currently included in strawberry distribution: ...\c\bin\zlib1.dll ...\c\include\zconf.h ...\c\include\zlib.h ...\c\lib\zlib.lib ...\c\lib\zdll.lib ...\c\lib\zlib1.a To understand the problem it is good to remind how mingw linker (ld.exe) does the library search. If you use a linker option -lxxx (where xxx is a libname) the mingw liker tries in given order the following files for c:\strawberry\c\lib (or any other dirs specified by -L option): - libxxx.dll.a - xxx.dll.a - libxxx.a - xxx.lib - libxxx.dll (yes, you can link directly with a DLL) - xxx.dll So obviously Zlib in current strawberry works just with the following ld options: -lzdll -lzlib However the mingw linker is not the only important element - you also need to satisfy ExtUtils::MakeMaker as it converts '-lxxx' options specified in INC param of WriteMakefile into full paths to corresponding *.a files. If a perl module has Makefile.PL like this: *** use ExtUtils::MakeMaker; WriteMakefile( LIBS => '-lz -lzlib -lzdll -llibz -lzlib1' ); *** On current strawberry will such a Makefile.PL end up with the following: Note (probably harmless): No library found for -lz Note (probably harmless): No library found for -lzlib Note (probably harmless): No library found for -lzdll Note (probably harmless): No library found for -llibz So only quite unusual and rarely used "-lzlib1" works. Important notes about ExtUtils::MakeMaker: - it seems that it ignores *.lib files - it has some Artificial Intelligence - e.g. for -lxxx it checks the existence of 'xxx.a' as well as 'libxxx.a' After some research it turned out that crazy makefile authors are using quite a lot variations for zlib linker option on Win32 platform. Here is the list of all occurrences I have found: -lz -lzlib -llibz -lzdll -lzlib1 I guess that strawberry should definitely support at least the most frequently used option -lz and perhaps also some others. But before I start with my suggestions what files to add/remove from strawberry package it is important to mention that ZLIB has sort of recommended-best-practice that can be found on - in short: - they advise to use official Zlib for Win32 release from - it talks just about dynamic linking - they prefer using the original ZLIB1.DLL from (not the same as ZLIB1.DLL in strawberry) - the official README.txt recommends for mingw to generate libzdll.a lib file (it implicates -lzdll ld option) Another more or less official Win32 release of Zlib comes from - this distribution contains both static and dynamic variant - the binaries (*.dll) and libs (*.a) were built with mingw compiler - they use officially recommended DLL name zlib1.dll (but the actual DLL is not identical to the one from - apart from they offer a static libz.a After some investigation it turned out that Zlib included in strawbery comes probably from binary build available at I guess it was taken together with XML2 binaries that are originated from the same source. - zlib1.dll from = zlib1.dll copy from gnuwin32 - zconf.h/zlib.h from = zconf.h/zlib.h from - *.lib files from were probably compiled from sources SUGGESTION 1) I would like to propose abandoning Zlib binaries and use binaries from gnuwin32 instead. If you will agree with my proposal to used our own build of LIBXML2/XSLT (discussed here: it will not be necessary to have Zlib from the same source. SUGGESTION 2) If we decide to have our own build of XML2/XSLT we can link zlib into xml2 statically and get completely rid of ZLIB1.DLL - after a discussion with jdb on IRC I agree that the static linking is the right way to avoid many problems. SUGGESTION 3) In my opinion we should support at least the following linker option -lz (means to have c:\strawberry\c\lib\libz.a) -lzlib (means to have c:\strawberry\c\lib\libzlib.a) I suggest both to be a static *.a libraries. I am not sure if we need to support also other variations (e.g. -llibz -lzdll -lzlib1) - it is just about some disk space for additional *.a files. To sum up - I propose to import the following files from gnuwin32 into strawberry: -> c:\strawberry\c\include\zconf.h -> c:\strawberry\c\include\zlib.h -> c:\strawberry\c\lib\libz.a -> c:\strawberry\c\lib\libzlib.a (duplicate) +remove existing Zlib based on binaries I would appreciate any feedback to this proposal. -- kmx
If we decide to include additional libraries - e.g. graphics libraries discussed here: - we are probably not able to avoid zlib1.dll. So idea of not including zlib1.dll was wrong. My updated proposal of using gnuwin32 zlib binaries is the following: -> c:\strawberry\c\include\zconf.h -> c:\strawberry\c\include\zlib.h -> c:\strawberry\c\lib\libzdll.a -> c:\strawberry\c\lib\libz.a -> c:\strawberry\c\lib\libzlib.a It means - using: -lz -lzdll = dynamic linking (dependency on zlib1.dll) - using: -lzlib = static linking (no DLL dependency) Or maybe we should only support zlib with dynamic linking and not to include static *.a at all - zlib1.dll will be there anyway so why to bother with static linking. Somebody should decide this. -- kmx
After another analyses I would go "100% dynamic linking" way. That means: -> c:\strawberry\c\include\zconf.h -> c:\strawberry\c\include\zlib.h -> c:\strawberry\c\lib\libzdll.a -> c:\strawberry\c\lib\libz.a -> c:\strawberry\c\lib\libzlib.a The only question is: do we want gnuwin32 or binary?
Just to record the latest agreement with CSJewell from IRC: - we are gonna use binaries - we are gonna support dynamic linking only
Hi, the enclosed is ready for release - it uses official ZLIB from - it supports just dynamic linking - it supports linker options -lz -lzdll -lzlib -- kmx

Message body not shown because it is not plain text.

Resolving since October release happened.

This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with to