Skip Menu |
 

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

Report information
The Basics
Id: 48671
Status: resolved
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: kmx [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: Ext-lib: Zlib support - change proposal
Download (untitled) / with headers
text/plain 4.9k
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
Download (untitled) / with headers
text/plain 963b
If we decide to include additional libraries - e.g. graphics libraries discussed here: https://rt.cpan.org/Ticket/Display.html?id=48759 - 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: 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.dll.a -> c:\strawberry\c\lib\libzdll.a zlib-1.2.3-lib.zip/lib/libz.dll.a -> c:\strawberry\c\lib\libz.a zlib-1.2.3-lib.zip/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
Download (untitled) / with headers
text/plain 473b
After another analyses I would go "100% dynamic linking" way. That means: 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.dll.a -> c:\strawberry\c\lib\libzdll.a zlib-1.2.3-lib.zip/lib/libz.dll.a -> c:\strawberry\c\lib\libz.a zlib-1.2.3-lib.zip/lib/libz.dll.a -> c:\strawberry\c\lib\libzlib.a The only question is: do we want gnuwin32 or zlib.net binary?
Download (untitled) / with headers
text/plain 142b
Just to record the latest agreement with CSJewell from IRC: - we are gonna use zlib.net binaries - we are gonna support dynamic linking only
Download (untitled) / with headers
text/plain 197b
Hi, the enclosed libzlib-1.2.3-bin_20090819.zip is ready for release - it uses official ZLIB from zlib.net - 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 is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.