threads / discuss / 204

zlib version, list archives

Subject: zlib version, list archives

## tl;dr

3 messages between Apr 21, 2005 and Apr 21, 2005.

replies: 2people: 3as markdown or json

Joel Schopp· Apr 21, 2005, 17:19 UTC · lore

I downloaded git-pasky 0.6.2. I cannot compile it because my zlib version is 1.1.4 and git-pasky relies on function deflateBound() which wasn't introduced until zlib version 1.2.x Is there a patch out there to work around this and maybe conditionally compile based on the zlib version?

I apologize in advance if this has already been asked, I cannot find an archive of this list. Could somebody point me to one?

Randy.Dunlap· Apr 21, 2005, 17:25 UTC · re: Joel Schopp · lore

Re: zlib version, list archives

On Thu, 21 Apr 2005 12:19:32 -0500 Joel Schopp wrote:
| I downloaded git-pasky 0.6.2.  I cannot compile it because my zlib 
| version is 1.1.4 and git-pasky relies on function deflateBound() which 
| wasn't introduced until zlib version 1.2.x  Is there a patch out there 
| to work around this and maybe conditionally compile based on the zlib 
| version?
| 
| I apologize in advance if this has already been asked, I cannot find an 
| archive of this list.  Could somebody point me to one?

http://marc.theaimsgroup.com/?l=git or http://dir.gmane.org/gmane.comp.version-control.git

--- ~Randy

David A. Wheeler· Apr 21, 2005, 23:27 UTC · re: Randy.Dunlap · lore

Porting to old zlib (deflateBound) & old mktemp (e.g., Red Hat Linux 9)

On Thu, 21 Apr 2005 12:19:32 -0500 Joel Schopp wrote:
Show 7 quoted lines
>| I downloaded git-pasky 0.6.2.  I cannot compile it because my zlib 
>| version is 1.1.4 and git-pasky relies on function deflateBound() which 
>| wasn't introduced until zlib version 1.2.x  Is there a patch out there 
>| to work around this and maybe conditionally compile based on the zlib 
>| version?
>  
>

Here's a quick (read: nasty, dreadful) hack to port git to older systems like Red Hat Linux 9 which have old versions of zlib & mktemp. Someone who actually spent two seconds on this can no doubt give you a better solution, but it "worked for me".

Edit sha1_file.c, and change the line:
 size = deflateBound(&stream, len);
to
 size = len + 1024; /* 1024=emergency extra space */
The "deflateBound" call just finds out the maximum amount of allocation 
space.
The documentation says that "deflateBound() may return a
conservative value that may be larger than /sourceLen/" in certain cases,
which worried me. So to be safe I just added a big pile of excess space 
to "len";
I suspect that "size = len" is sufficient but I didn't investigate it.
If you're trying to get this to work on Red Hat Linux 9, you'll
have another problem too: old versions of "mktemp"
don't support the "-t" option. Other old distributions will
have the same problem.  To find these cases, do:
 grep "mktemp.*-t" *
and edit all the files to remove the "-t" option from mktemp.
That's the bare minimum to make it work; a much
cleaner solution would to specify the tempdir, e.g.,:
 mktemp ${TMPDIR:-/tmp/}gitci.XXXXX
or even more portably, write the shell code to set TMPDIR to "/tmp"
locally if it's not set, then use $TMPDIR everywhere.

Not a good final solution, but enough to get started in the interim. In long term, this should be made more portable, but it's only ~2 weeks old after all. Some people are trying to fly this plane to transport a buffalo herd, while others are working to attach the wings :-).

--- David A. Wheeler

← back to recent threads