[Python-Dev] zlib module doesn't build - inflateCopy() not found

[Guido van Rossum]

On 5/20/06, Georg Brandl <g.brandl at gmx.net> wrote:
> Martin v. Löwis wrote:
> > Guido van Rossum wrote:
> >> It seems I have libz 1.1.4. Is this no longer supported?
> >
> > Apparently so. This function started to be used with
> >
> > ------------------------------------------------------------------------
> > r46012 | georg.brandl | 2006-05-16 09:38:27 +0200 (Di, 16 Mai 2006) | 3
> > lines
> > Geänderte Pfade:
> >    M /python/trunk/Doc/lib/libzlib.tex
> >    M /python/trunk/Lib/test/test_zlib.py
> >    M /python/trunk/Misc/NEWS
> >    M /python/trunk/Modules/zlibmodule.c
> >
> > Patch #1435422: zlib's compress and decompress objects now have a
> > copy() method.
> >
> > ------------------------------------------------------------------------
> >
> > zlib itself contains inflateCopy since
> >
> > Changes in 1.2.0 (9 March 2003)
> >     - Added inflateCopy() function to record state for random access on
> >       externally generated deflate streams (e.g. in gzip files)
>  >
> > The options for Python now are these:
> > 1. require users to install zlib 1.2.x if they want the zlib module
> >    drawback: more work for the system administrator

That's unacceptable; I'd have to fight a whole layer of burocracy to
change the system image (and I wouldn't even want to do this since one
premise here is that engineering workstations are interchangeable).

> > 2. conditionalize copy/uncopy on the system zlib being 1.2.x
> >    drawback: Python applications relying on these functions would
> >    break if the system zlib is too old

That would be fine for me. Since the feature is apparently brand new
(in Python) I doubt that I'd miss it.

> > 3. make setup.py fall back to the bundled zlib if the system zlib
> >    is too old
> >    drawback: you get all the problems of static linking, e.g.
> >    the size increase, and the problems with two zlib versions
> >    living in the same address space for some embedded Python
> >    applications

That would work too (probably better). As long as it prints some kind
of warning durning build IMO this would be the best option. The
drawbacks don't matter for me.

> > I'm not volunteering to implement any of the options.
>
> Of course, option 4 is to revert the patch if none of these options
> are acceptable.

Not so quick. :-)

What was the purpose of the patch in the first place?

If you could volunteer #3 that would be great IMO.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)