Upgrade zlib to 1.2.6 #12800

jdemeyer · 2012-04-03T16:13:07Z

Changes in 1.2.6 (29 Jan 2012)
- Update the Pascal interface in contrib/pascal
- Fix function numbers for gzgetc_ in zlibvc.def files
- Fix configure.ac for contrib/minizip [Schiffer]
- Fix large-entry detection in minizip on 64-bit systems [Schiffer]
- Have ./configure use the compiler return code for error indication
- Fix CMakeLists.txt for cross compilation [McClure]
- Fix contrib/minizip/zip.c for 64-bit architectures [Dalsnes]
- Fix compilation of contrib/minizip on FreeBSD [Marquez]
- Correct suggested usages in win32/Makefile.msc [Shachar, Horvath]
- Include io.h for Turbo C / Borland C on all platforms [Truta]
- Make version explicit in contrib/minizip/configure.ac [Bosmans]
- Avoid warning for no encryption in contrib/minizip/zip.c [Vollant]
- Minor cleanup up contrib/minizip/unzip.c [Vollant]
- Fix bug when compiling minizip with C++ [Vollant]
- Protect for long name and extra fields in contrib/minizip [Vollant]
- Avoid some warnings in contrib/minizip [Vollant]
- Add -I../.. -L../.. to CFLAGS for minizip and miniunzip
- Add missing libs to minizip linker command
- Add support for VPATH builds in contrib/minizip
- Add an --enable-demos option to contrib/minizip/configure
- Add the generation of configure.log by ./configure
- Exit when required parameters not provided to win32/Makefile.gcc
- Have gzputc return the character written instead of the argument
- Use the -m option on ldconfig for BSD systems [Tobias]
- Correct in zlib.map when deflateResetKeep was added

In particular, it builds on the Skynet machine mark (SunOS 5.10-32) with GCC-4.7.0, unlike zlib-1.2.5.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/zlib-1.2.6.spkg

CC: @orlitzky

Component: packages: standard

Author: Jeroen Demeyer

Reviewer: Michael Orlitzky, Julien Puydt, Leif Leonhardy

Merged: sage-5.0.beta14

Issue created by migration from https://trac.sagemath.org/ticket/12800

The text was updated successfully, but these errors were encountered:

jdemeyer · 2012-04-03T16:24:02Z

Author: Jeroen Demeyer

orlitzky · 2012-04-11T04:05:24Z

comment:2

We might as well just get of the commented-out lines. We're using version control, after all. If they're done in a separate commit, just those lines can be hg backouted.

orlitzky · 2012-04-11T04:09:44Z

comment:3

Alternately, fix the patch routine =)

jdemeyer · 2012-04-11T06:23:16Z

comment:4

Well, #12432 adds a patch again, so it doesn't really matter.

SnarkBoojum · 2012-04-11T07:58:40Z

comment:5

The spkg compiled fine with sage-4.8 on ARM.

nexttime · 2012-04-11T12:08:47Z

Attachment: zlib-1.2.6.reviewer-ll.patch.gz

Reviewer patch. Apply to Jeroen's spkg.

nexttime · 2012-04-11T12:11:04Z

Reviewer: Michael Orlitzky, Julien Puydt, Leif Leonhardy

nexttime · 2012-04-11T12:11:04Z

comment:6

spkg-install needs some work; see my attached reviewer patch.

Doesn't make sense to comment out the patch loop; I wouldn't have deleted the patches/ directory either (but my patch doesn't restore it).

nexttime · 2012-04-11T12:14:37Z

Replying to @jdemeyer:

Changes in 1.2.6 (29 Jan 2012)
[...]
In particular, it builds on the Skynet machine mark (SunOS 5.10-32) with GCC-4.7.0, unlike zlib-1.2.5.

Well, none of the other changes seem to be relevant for Sage. (But regarding the size of the spkg, it IMHO isn't worth deleting some parts from the upstream tree.)

jdemeyer · 2012-04-11T12:54:55Z

Attachment: zlib-1.2.6.diff.gz

Diff for the zlib spkg. For review only

jdemeyer · 2012-04-11T12:56:21Z

comment:8

Leif, I added almost all of your changes, the spkg is at the same location. I patched the patch loop in a different way, now it is:

# Apply all patches
for patch in ../patches/*.patch; do
    [ -f "$patch" ] || continue
    basename "$patch"
    if ! patch -p1 <"$patch"; then
        echo >&2 "Error: patch '$patch' failed to apply."
        exit 1
    fi
done

SnarkBoojum · 2012-04-11T13:06:25Z

comment:9

Does that loop works even if the ../patches/ directory is empty? Or does it give a file not found error? Not that it matters as long as there is a patch, but that's the first thing that came to my mind reading this...

jdemeyer · 2012-04-11T13:11:53Z

comment:10

Replying to @SnarkBoojum:

Does that loop works even if the ../patches/ directory is empty? Or does it give a file not found error?

If ../patches is either empty or non-existent, then ../patches/* will expand literally to "../patches/*". Since "../patches/*" isn't a file, the line

[ -f "$patch" ] || continue

will ensure that there are no error messages.

nexttime · 2012-04-11T16:17:17Z

comment:11

Replying to @jdemeyer:

Replying to @SnarkBoojum:

Does that loop works even if the ../patches/ directory is empty? Or does it give a file not found error?

If ../patches is either empty or non-existent, then ../patches/* will expand literally to "../patches/*". Since "../patches/*" isn't a file, the line
[ -f "$patch" ] || continue
will ensure that there are no error messages.

Yes, but it then would make more sense to break rather than continue.

But to perform some loop-invariant code motion, it would be better to just use

ls ../patches/*.patch &>/dev/null &&
echo "Applying patches to upstream source..." &&
for patch in ../patches/*.patch; do
    ...

nexttime · 2012-04-11T16:23:44Z

comment:12

P.S.:

$ ls patches/
*.patch

Then your continue would be correct... ;-)

nexttime · 2012-04-11T16:27:10Z

comment:13

Replying to @nexttime:

P.S.:
$ ls patches/
*.patch
Then your continue would be correct... ;-)

Although in that case also [ -f "$patch" ] yields true, so continue isn't reached.

jdemeyer · 2012-04-11T17:32:54Z

comment:14

Replying to @nexttime:

Yes, but it then would make more sense to break rather than continue.

I don't think there is anything wrong with my code. It's simple and actually catches more special cases than your proposals (such as patches/foo.patch being a directory).

nexttime · 2012-04-11T17:50:30Z

comment:15

Replying to @jdemeyer:

Replying to @nexttime:

Yes, but it then would make more sense to break rather than continue.

I don't think there is anything wrong with my code. It's simple and actually catches more special cases than your proposals (such as patches/foo.patch being a directory).

Well, I think the only "special cases" we want to (or have to) handle here are:

../patches/ doesn't exist.
The directory exists, but it is empty, or at least doesn't contain files matching *.patch.

(I won't insist on changing the continue, but it seems more natural [and actually is more efficient] to place a single test outside the loop. Also, conditionally printing "Applying patches..." seems reasonable to me.)

If you wanted to go triple-safe, you'd have to use [ -r "$patch" ] instead of [ -f ... ].

SnarkBoojum · 2012-04-11T18:04:20Z

comment:16

Debian maintainers manage their patches to upstream using
quilt.

Debian has about fourty thousand packages, with eleven official ports and a few unofficial ones, so I guess they know what they're doing.

orlitzky · 2012-04-11T18:07:40Z

comment:17

We could just apply the patches in a mercurial queue, since we ship a repo with every spkg. Anyway, this is pointless: I've built a fresh beta13 with this spkg, and it passes a ptestlong. I manually checked the error conditions. When you figure out what to do with the patch routine (delete it!), it's ready.

nexttime · 2012-04-11T18:28:24Z

comment:18

Replying to @orlitzky:

I've built a fresh beta13 with this spkg, and it passes a ptestlong. I manually checked the error conditions. When you figure out what to do with the patch routine (delete it!), it's ready.

Yep. I'm ok with the spkg as is, so setting it to positive review.

If anybody should disagree, feel free to revert that.

jdemeyer · 2012-04-19T06:40:48Z

Merged: sage-5.0.beta14

jhpalmieri · 2012-06-14T14:40:22Z

comment:20

I'm having problems with this on the OpenSolaris machine hawk: when trying to build sage-5.1.beta3, I see

gcc -O3  -D_LARGEFILE64_SOURCE=1 -o example64 example64.o -L. libz.a
gcc -O3  -D_LARGEFILE64_SOURCE=1 -o minigzip64 minigzip64.o -L. libz.a
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _length_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _dist_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _dist_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _length_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _dist_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _dist_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _length_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol _dist_code: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol zcalloc: a GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file deflate.lo: symbol zcfree: a GOT relative relocation must reference a local symbol
collect2: ld returned 1 exit status
make[2]: *** [libz.so.1.2.6] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/export/home/palmieri/testing/clean/sage-5.1.beta3/spkg/build/zlib-1.2.6/src'
Error building zlib.

Any suggestions?

jdemeyer · 2012-06-15T06:43:37Z

comment:21

I don't have the same problem on hawk. Are you using /usr/local/bin/gcc, i.e. gcc 4.4.3 on hawk?

Compiling with CC=suncc should also work.

jhpalmieri · 2012-06-15T17:30:51Z

comment:22

I had some old environment variables set. Unsetting them seems to help.

jdemeyer added this to the sage-5.0 milestone Apr 3, 2012

jdemeyer added c: packages: standard labels Apr 3, 2012

This comment has been minimized.

Sign in to view

jdemeyer added the s: needs review label Apr 3, 2012

nexttime mannequin added s: needs work and removed s: needs review labels Apr 11, 2012

jdemeyer added s: needs review and removed s: needs work labels Apr 11, 2012

nexttime mannequin added s: positive review and removed s: needs review labels Apr 11, 2012

jdemeyer removed the s: positive review label Apr 19, 2012

jdemeyer closed this as completed Apr 19, 2012

sagetrac-mariah mannequin mentioned this issue Mar 18, 2013

Allow building Sage with GCC-4.7.x #12751

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade zlib to 1.2.6 #12800

Upgrade zlib to 1.2.6 #12800

jdemeyer commented Apr 3, 2012

This comment has been minimized.

jdemeyer commented Apr 3, 2012

orlitzky commented Apr 11, 2012

orlitzky commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

orlitzky commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 19, 2012

jhpalmieri commented Jun 14, 2012

jdemeyer commented Jun 15, 2012

jhpalmieri commented Jun 15, 2012

Upgrade zlib to 1.2.6 #12800

Upgrade zlib to 1.2.6 #12800

Comments

jdemeyer commented Apr 3, 2012

This comment has been minimized.

jdemeyer commented Apr 3, 2012

orlitzky commented Apr 11, 2012

orlitzky commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

SnarkBoojum mannequin commented Apr 11, 2012

orlitzky commented Apr 11, 2012

nexttime mannequin commented Apr 11, 2012

jdemeyer commented Apr 19, 2012

jhpalmieri commented Jun 14, 2012

jdemeyer commented Jun 15, 2012

jhpalmieri commented Jun 15, 2012