| 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
http://www.zlib.net/DLL_FAQ.txt - in short:
- they advise to use official Zlib for Win32 release from
http://www.zlib.net/zlib123-dll.zip
- it talks just about dynamic linking
- they prefer using the original ZLIB1.DLL from zlib.net (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
http://gnuwin32.sourceforge.net/packages.html
- 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 zlib.net)
- apart from zlib.net they offer a static libz.a
After some investigation it turned out that Zlib included in strawbery
comes probably from binary build available at zlatkovic.com. I guess it
was taken together with XML2 binaries that are originated from the same
source.
- zlib1.dll from zlatkovic.com = zlib1.dll copy from gnuwin32
- zconf.h/zlib.h from zlatkovic.com = zconf.h/zlib.h from zlib.net
- *.lib files from zlatkovic.com were probably compiled from sources
SUGGESTION 1) I would like to propose abandoning zlatkovic.com 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:
http://rt.cpan.org/Public/Bug/Display.html?id=48576) 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:
zlib-1.2.3-lib.zip/include/zconf.h -> c:\strawberry\c\include\zconf.h
zlib-1.2.3-lib.zip/include/zlib.h -> c:\strawberry\c\include\zlib.h
zlib-1.2.3-lib.zip/lib/libz.a -> c:\strawberry\c\lib\libz.a
zlib-1.2.3-lib.zip/lib/libz.a -> c:\strawberry\c\lib\libzlib.a (duplicate)
+remove existing Zlib based on zlatkovic.com binaries
I would appreciate any feedback to this proposal.
--
kmx