Opened 7 years ago

Closed 7 years ago

#13914 closed defect (fixed)

Install zlib shared objects on Cygwin

Reported by: jpflori Owned by: tbd
Priority: major Milestone: sage-5.7
Component: packages: standard Keywords: cygwin zlib spkg
Cc: kcrisman, dimpase Merged in: sage-5.7.beta4
Authors: Jean-Pierre Flori Reviewers: Dmitrii Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by 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

Attachments (1)

zlib-1.2.6.p0.diff (954 bytes) - added by jpflori 7 years ago.
Spkg diff, for review only.

Download all attachments as: .zip

Change History (37)

comment:1 Changed 7 years ago by jpflori

  • Status changed from new to needs_review

comment:2 follow-up: Changed 7 years ago by kcrisman

Is this somehow related to #13354?

comment:3 in reply to: ↑ 2 Changed 7 years ago by jpflori

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.

comment:4 follow-up: Changed 7 years ago by jpflori

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).

comment:5 in reply to: ↑ 4 Changed 7 years ago by kcrisman

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.

comment:6 Changed 7 years ago by jpflori

  • Cc kcrisman added
  • Description modified (diff)

comment:7 Changed 7 years ago by jpflori

  • Status changed from needs_review to needs_work

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

comment:8 Changed 7 years ago by jpflori

Groumpf that was SHARED_MOD, not SHARED_OBJECT...

Changed 7 years ago by jpflori

Spkg diff, for review only.

comment:9 Changed 7 years ago by jpflori

  • Status changed from needs_work to needs_review

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

comment:10 Changed 7 years ago by kcrisman

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.)

comment:11 Changed 7 years ago by jpflori

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.

comment:12 follow-up: Changed 7 years ago by kcrisman

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.

comment:13 follow-up: Changed 7 years ago by jpflori

  • Cc dimpase added

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

comment:14 in reply to: ↑ 13 ; follow-up: Changed 7 years ago by 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...

comment:15 in reply to: ↑ 14 Changed 7 years ago by dimpase

  • Status changed from needs_review to positive_review

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.

comment:16 in reply to: ↑ 12 ; follow-up: Changed 7 years ago by 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.

comment:17 Changed 7 years ago by jpflori

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.

comment:18 in reply to: ↑ 16 Changed 7 years ago by dimpase

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.

comment:19 follow-up: Changed 7 years ago by jdemeyer

  • Reviewers set to Dmitrii Pasechnik

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

comment:20 in reply to: ↑ 19 ; follow-up: Changed 7 years ago by 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.

comment:21 follow-up: Changed 7 years ago by kcrisman

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

comment:22 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by dimpase

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.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 7 years ago by 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.

comment:24 in reply to: ↑ 23 Changed 7 years ago by dimpase

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.

comment:25 Changed 7 years ago by jpflori

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

comment:26 in reply to: ↑ 20 Changed 7 years ago by dimpase

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

comment:27 Changed 7 years ago by jdemeyer

  • Status changed from positive_review to needs_work

comment:28 Changed 7 years ago by jpflori

Does it work with gcc?

comment:29 Changed 7 years ago by jpflori

  • Status changed from needs_work to positive_review

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.

comment:30 Changed 7 years ago by jdemeyer

  • Status changed from positive_review to needs_work

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.

comment:31 Changed 7 years ago by jpflori

Oh, ok, my fault then.

comment:32 follow-up: Changed 7 years ago by jpflori

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.

comment:33 Changed 7 years ago by jpflori

  • Status changed from needs_work to needs_review

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.

comment:34 in reply to: ↑ 32 Changed 7 years ago by jdemeyer

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.

comment:35 Changed 7 years ago by dimpase

  • Status changed from needs_review to positive_review

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.

comment:36 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.7.beta4
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.