Install zlib shared objects on Cygwin

[jpflori]

We need to modify the makefile so that SHARED_OBJECT is set to 1.

Use spkg at
http://boxen.math.washington.edu/home/jpflori/zlib-1.2.6.p0.spkg

CC: @kcrisman @dimpase

Component: packages: standard

Keywords: cygwin zlib spkg

Author: Jean-Pierre Flori

Reviewer: Dmitrii Pasechnik

Merged: sage-5.7.beta4

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

[kcrisman]

comment:2

Is this somehow related to #13354?

[jpflori]

comment:3

Replying to @kcrisman:

Is this somehow related to #13354?

Not at all, it is just that we did not customize the win32 makefile correctly before.
Whence the need to install zlib and zlib-devel (or Cygwin equivalents, not sure of the name now) because our own zlib was lacking shared objects.

[jpflori]

comment:4

I mean it is unrelated because zlib does not use autotools at all.

If you really want it can be related in the sense that in the end the problem is that shared objects are not installed (even though in the autotools case they are not even built).

[kcrisman]

comment:5

If you really want it can be related in the sense that in the end the problem is that shared objects are not installed (even though in the autotools case they are not even built).

That is what I meant, I guess.

So this would remove the zlib-devel dependency on Win 7, okay, I understand now.

[jpflori]

comment:7

Something wrong here, this does not install the shared files properly...

[jpflori]

comment:8

Groumpf that was SHARED_MOD, not SHARED_OBJECT...

[jpflori]

Spkg diff, for review only.

[jpflori]

comment:9

Attachment: zlib-1.2.6.p0.diff.gz

Spkg should be fine now and installed successfully on my system.

[kcrisman]

comment:10

Well, at least it installs on mine as well, though of course I already had zlib. I guess the diff looks ok too and only touches Cygwin, correct? Is there any other spkg or something I should wait for building to give this positive review (i.e., one that depends on it), and how would I know if things were linked against this as opposed to the system one? (I don't know what zlib does or how it is used, big surprise.)

[jpflori]

comment:11

You can run ldd on libs which should use zlib, I'd say it's the case of libgd and libfreetype (from inside a Sage shell).
Or you could just check that the zlib1.dll file is indeed installed.

[kcrisman]

comment:12

Sadly, after a required BLODA upgrade to allow my internet access with this machine, Sage won't build - nothing reliable, just the usual horrible stuff and rebasing just delays the pain. Python package in particular is affected. So I wonder whether we should just do this and assume it works on XP. Sorry.

[jpflori]

comment:13

Maybe Dima can have a look?
The changes are quite simple so this should not be a hassle.

[dimpase]

comment:14

Replying to @jpflori:

Maybe Dima can have a look?
The changes are quite simple so this should not be a hassle.

I'll try to build sage 5.7.beta0 on Cygwin...

[dimpase]

comment:15

Replying to @dimpase:

Replying to @jpflori:

Maybe Dima can have a look?
The changes are quite simple so this should not be a hassle.

I'll try to build sage 5.7.beta0 on Cygwin...

OK, it builds and works on 64-bit Windows 7 with the latest stable Cygwin, and native Cygwin gcc and gfortran.
Needed to rebase 2 times during the build. Running tests now.

This ticket looks good, positive review.

[jdemeyer]

comment:16

Replying to @kcrisman:

rebasing just delays the pain.

Speaking of which, do you by chance use the script $SAGE_LOCAL/bin/sage-rebase_sage.sh? Just wondering whether that's used at all.

[jpflori]

comment:17

I did not even know it existed...
But, on my side at least, it seems that somehow the situation has gotten better recently.
For my last attempt, I just had to rebase once after installing everything to be able to launch Sage (although after reinstalling some spkg I got stuck with a fork error).
Before that I sometimes had to do horrible stuff like rebasing in the middle of the build of the Maxim spkg, which was kind of painful.

[dimpase]

comment:18

Replying to @jdemeyer:

Replying to @kcrisman:

rebasing just delays the pain.

Speaking of which, do you by chance use the script $SAGE_LOCAL/bin/sage-rebase_sage.sh? Just wondering whether that's used at all.

this script, which basically runs the same 2 shell commands as we use to rebase Sage, must be run in a non-cygwin shell (Cygwin includes a copy of dash for this purpose), not in bash. Perhaps we should convert it into a dash script.

[jdemeyer]

comment:19

My question about sage-rebase_sage.sh was more: should be keep it or can it be removed?

[dimpase]

comment:20

Replying to @jdemeyer:

My question about sage-rebase_sage.sh was more: should be keep it or can it be removed?

with some work, it can be made useful. I'll open a ticket for this.

[kcrisman]

comment:21

Huh, I didn't know this. Note that on some systems "ash" is needed, not "dash".

[dimpase]

comment:22

Replying to @kcrisman:

Huh, I didn't know this. Note that on some systems "ash" is needed, not "dash".

Well, I suppose it's the matter of installing dash.

[kcrisman]

comment:23

Huh, I didn't know this. Note that on some systems "ash" is needed, not "dash".

Well, I suppose it's the matter of installing dash.

Then that would need to be an additional prerequisite for building Sage on Cygwin, which it currently is not.

[dimpase]

comment:24

Replying to @kcrisman:

Huh, I didn't know this. Note that on some systems "ash" is needed, not "dash".

Well, I suppose it's the matter of installing dash.

Then that would need to be an additional prerequisite for building Sage on Cygwin, which it currently is not.

we should switch from ash to dash, at least that's what Cygwin people were saying already in 2009.

[jpflori]

comment:25

I'd say let's keep the file, I guess it is really samll and can be useful for people not used to rebasing.

[dimpase]

comment:26

Replying to @dimpase:

Replying to @jdemeyer:

My question about sage-rebase_sage.sh was more: should be keep it or can it be removed?

with some work, it can be made useful. I'll open a ticket for this.

please see #14031

[jdemeyer]

comment:27

This fails to install on OS X 10.8: http://build.sagemath.org/sage/builders/Dehaye%20%28OSX%2010.8%20x86_64%29/builds/56/steps/shell_6/logs/zlib

[jpflori]

comment:28

Does it work with gcc?

[jpflori]

comment:29

Anyway I don't really think this ticket is related.
Here we only touch code in Cygwin specific part (unless $UNAME = CYGWIN on Os X).
So I'm putting this back to positive review.

[jdemeyer]

comment:30

PLEASE at least double-check before saying that it's not your fault, especially when the failure is so obvious.

Your spkg is totally badly packaged, it even contains compiled .o files.

[jpflori]

comment:31

Oh, ok, my fault then.

[jpflori]

comment:32

Next time state the obvious problem at once instead of linking to a not so obvious for anyone log...
Especially when it seems that all objects are rebuilt there and the problematic libz.a is repackaged correctly.

And I don't usually look into the src folder, too bad this one comes from a test build and is not vanilla.

[jpflori]

comment:33

The newly uploaded spkg should be clean.
It stills builds on Cygwin and Linux correctly (note the previous one did as well).
No access to Os X, but checking the src dir is vanilla should be enough.

[jdemeyer]

comment:34

Replying to @jpflori:

Next time state the obvious problem at once

"obvious" refered to the fact that a zlib build failure might likely be caused by a zlib package update. I hadn't checked the spkg at that point.

[dimpase]

comment:35

I've checked that the spkg src/ directory didn't change from the previous version. It also builds on OSX 10.6.8 and on Cygwin. Positive review.

[jdemeyer]

Merged: sage-5.7.beta4