upgrade polymake to version 2.12-rc3

tkluck commented 11 years ago

Here's an updated package for Polymake. The new package is a lot simpler than the old one, because this upstream version comes with a sane configure script and installs everything in standard locations.

This depends on the boost-cropped spkg >= 1.52.0

This is a very long compilation. That's partly due to the fact that the spkg-install disables parallel build, because apparently that used to be buggy. I've been cautious and left that disabled, but I wouldn't be surprised if we could enable it again -- if the configure script has had an overhaul, then maybe so has the makefile.

I'm working on a new Python interface that takes advantage of the new C++ api (via Cython) instead of writing data to a file and using pexpect (yuck). That'll take a while and be a different ticket.

Here's the link to the new package:

http://www.infty.nl/misc/polymake-2.12.spkg

Component: packages: experimental

Reviewer: Matthias Koeppe, Karl-Dieter Crisman

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

kcrisman commented 11 years ago

Changed dependencies from 13767 to #13767

kcrisman commented 11 years ago

comment:3

Does this fix #5488 as well?

tkluck commented 11 years ago

comment:4

Yes it does.

tkluck commented 11 years ago

comment:5

I updated this to polymake-2.12 (which is bit-for-bit identical to polymake-2.12-rc3). I fixed a version number typo in SPKG.txt and updated it to reflect the rename boost-cropped -> boost_cropped.

I also removed the disabling of parallel build. The polymake documentation now recommends using parallel build, so there shouldn't be any need for that anymore: http://www.polymake.org/doku.php/howto/install

The current package has md5sum 51d3b6da0ae60ac417e418bc89da1189.

tkluck commented 11 years ago

Description changed:

--- 
+++ 
@@ -8,4 +8,4 @@

 Here's the link to the new package:

-http://infty.nl/misc/polymake-2.12-rc3.spkg
+http://infty.nl/misc/polymake-2.12.spkg

kcrisman commented 11 years ago

comment:6

I guess it stays experimental for now - here's the message on a Mac OS X 10.7. We explicitly do NOT want Fink as a prereq. Does anybody even still use Fink? ;-)

gcc version 4.6.3 (GCC) 
****************************************************
The Fink package system is a mandatory prerequisite to build and use polymake under MacOS.
Please refer to http://polymake.mathematik.tu-darmstadt.de/doku.php/mac for details and installation instructions.
If you already have Fink installed at a non-standard location, please specify it using option --with-fink
Failed to configure.

real    0m0.792s
user    0m0.042s
sys 0m0.024s
************************************************************************
Error installing package polymake-2.12
************************************************************************

That said, we could probably get around that by hacking their installation procedure, especially since http://polymake.mathematik.tu-darmstadt.de/doku.php/mac apparently doesn't exist.

In fact, http://polymake.mathematik.tu-darmstadt.de/doku.php/howto/mac (do you want to report that upstream?) says that

compiling sources from scratch without Fink (polymake 2.10 or later)

is supported, if you have java (?!?!?!)

Anyway, I don't care about this for experimental, but at least one person I know who was VERY interested in using polymake through Sage uses Mac. Reading through their stuff, they just need a real gcc (not the Apple compiler on modern ones), which we provide, and perl, which is a prereq for Sage. See without fink for a full list of prereqs, which I think we include - including, soon, the full Boost headers - and some compiling options.

Timo, if you aren't interested in doing this :-) then perhaps you can open a ticket with some of this information for moving polymake to an optional spkg.

tkluck commented 11 years ago

comment:7

Replying to @kcrisman:

That said, we could probably get around that by hacking their installation procedure, especially since http://polymake.mathematik.tu-darmstadt.de/doku.php/mac apparently doesn't exist.

From quickly browsing the sources, it seems possible that this would compile without issue if we call

./configure --without-java --with-fink=no
make -j4

Could you try this in a sage shell:

sage -sh

in a sage installation containing the boost_cropped package from #13767?

Timo, if you aren't interested in doing this :-) then perhaps you can open a ticket with some of this information for moving polymake to an optional spkg.

I don't have access to a Mac, but if the above naive attempt works, I'll update the spkg. (I would be willing to do some more investigation if someone could give me ssh access to OSX.)

kcrisman commented 11 years ago

comment:8

From quickly browsing the sources, it seems possible that this would compile without issue if we call
./configure --without-java --with-fink=no
make -j4
Could you try this in a sage shell:
sage -sh
in a sage installation containing the boost_cropped package from #13767?

You mean inside of a source folder for polymake, or with respect to this spkg? Let me know and I'll try it.

I don't have access to a Mac, but if the above naive attempt works, I'll update the spkg. (I would be willing to do some more investigation if someone could give me ssh access to OSX.)

I can't do that, but if you have access to the sage.math cluster, someone might be able to do so.

tkluck commented 11 years ago

comment:9

Replying to @kcrisman:

You mean inside of a source folder for polymake, or with respect to this spkg? Let me know and I'll try it.

Either in a source folder for polymake, or in the ./src directory of this spkg. Both should be equivalent.

kcrisman commented 11 years ago

comment:10

$ ./configure --without-java --with-fink=no
WARNING: perl module Term::ReadLine::Gnu required for polymake not found on your machine.
         Please be sure to install it prior to starting to use polymake. 
         If you have installed them in a non-standard location 
         please add the path to the environment variable PERL5LIB

Configuration goes on, nevertheless.

After then doing make install and running it, I get

polymake:  WARNING: created private directory /Users/.../.polymake
Welcome to polymake version 2.12, released on March 19, 2012
Copyright (c) 1997-2012
Ewgenij Gawrilow, Michael Joswig (TU Darmstadt)
http://www.polymake.org

This is free software licensed under GPL; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Loading applications now...polymake: Creating tree /Users/.../.polymake/wrappers/core for automatically generated private C++/perl wrappers
polymake:  ERROR: "/usr/local/share/polymake/apps/graph/rules/postscript.rules", line 37: unknown label 'postscript'

But I have a feeling that all this is actually not that hard to fix.

kcrisman commented 11 years ago

comment:11

polymake:  WARNING: created private directory /Users/.../.polymake
Welcome to polymake version 2.12, released on March 19, 2012
Copyright (c) 1997-2012
Ewgenij Gawrilow, Michael Joswig (TU Darmstadt)
http://www.polymake.org

This is free software licensed under GPL; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Loading applications now...polymake: Creating tree /Users/.../.polymake/wrappers/core for automatically generated private C++/perl wrappers
polymake:  ERROR: "/usr/local/share/polymake/apps/graph/rules/postscript.rules", line 37: unknown label 'postscript'

But I have a feeling that all this is actually not that hard to fix.

See for instance here, though I couldn't actually apply the patch, so maybe it's been incorporated already... which means I have a different problem? Or is it the whole missing the perl module thing?

kcrisman commented 11 years ago

comment:12

I'm wondering also about this in spkg-install

./configure --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL"

should we add --with-readline and --with-mpfr to be $SAGE_LOCAL as well?

I tried to add the appropriate Perl modules for this but found some trouble - as well as noted that the specific versions of the xml thing mentioned aren't even available at CPAN...

tkluck commented 11 years ago

comment:13

Replying to @kcrisman:

I'm wondering also about this in spkg-install
./configure --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL"
should we add --with-readline and --with-mpfr to be $SAGE_LOCAL as well?

That probably makes sense.

I tried to add the appropriate Perl modules for this but found some trouble - as well as noted that the specific versions of the xml thing mentioned aren't even available at CPAN...

This sounds like something that upstream could be contacted about.

Looking back at:

polymake: ERROR: "/usr/local/share/polymake/apps/graph/rules/postscript.rules", line 37: unknown label 'postscript'

This bothers me. Why does it use a system-wide install in /usr/local/share instead of something in $SAGE_LOCAL?

I have a hunch that the root of the trouble on OSX may be that the configure script uses the perl variable $^O to check what operating system Perl was compiled for. It then uses that to make assumptions about which libraries are available, and where to find them. I wonder what would happen if only we could just override this $^O variable from the command line (which seems impossible) or when we just patch the configure.pl script to start with setting $^O to linux.

kcrisman commented 11 years ago

comment:14

I'm wondering also about this in spkg-install
./configure --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL"
should we add --with-readline and --with-mpfr to be $SAGE_LOCAL as well?
That probably makes sense.

Ok.

I tried to add the appropriate Perl modules for this but found some trouble - as well as noted that the specific versions of the xml thing mentioned aren't even available at CPAN...

This sounds like something that upstream could be contacted about.

Yes, and the bad error message about the Mac page.

Looking back at:

polymake: ERROR: "/usr/local/share/polymake/apps/graph/rules/postscript.rules", line 37: unknown label 'postscript'

This bothers me. Why does it use a system-wide install in /usr/local/share instead of something in $SAGE_LOCAL?

That's because I just did make install because I couldn't use the spkg-install.

I have a hunch that the root of the trouble on OSX may be that the configure script uses the perl variable $^O to check what operating system Perl was compiled for. It then uses that to make assumptions about which libraries are available, and where to find them. I wonder what would happen if only we could just override this $^O variable from the command line (which seems impossible) or when we just patch the configure.pl script to start with setting $^O to linux.

I have no idea, but you may be right.

tkluck commented 11 years ago

comment:15

Replying to @kcrisman:

Looking back at:

polymake: ERROR: "/usr/local/share/polymake/apps/graph/rules/postscript.rules", line 37: unknown label 'postscript'

This bothers me. Why does it use a system-wide install in /usr/local/share instead of something in $SAGE_LOCAL?

That's because I just did make install because I couldn't use the spkg-install.

I see. Could you test the following in a sage shell (sage -sh) inside the polymake source directory:

./configure --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL" --without-java --with-fink=no
make -j4
make install

and see whether it works? Because it sounds like the prefix wasn't set correctly, and I'm not sure whether that could give problems. There should be no need to use sudo. Maybe try your --with-readline and --with-mpfr suggestions, too.

kcrisman commented 11 years ago

comment:16

Well, everything is fine except

$ ../../../../local/bin/polymake
Welcome to polymake version 2.12, released on March 19, 2012
Copyright (c) 1997-2012
Ewgenij Gawrilow, Michael Joswig (TU Darmstadt)
http://www.polymake.org

This is free software licensed under GPL; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Loading applications now...Can't locate object method "new" via package "Term::ReadLine::Gnu" at (eval 358) line 4, <GEN7> line 143.

So we definitely need this Perl package. And I'm having trouble installing it, I think because of it downloading a version for Mac but needing a linux one or something, as you suggest.

$ perl -MCPAN -e 'install Term::ReadLine::Gnu'
Going to read '/Users/.../.cpan/Metadata'  Database was generated on Thu, 28 Feb 2013 03:07:45 GMT
Running install for module 'Term::ReadLine::Gnu'
Running make for H/HA/HAYASHI/Term-ReadLine-Gnu-1.20.tar.gz
Checksum for /Users/.../.cpan/sources/authors/id/H/HA/HAYASHI/Term-ReadLine-Gnu-1.20.tar.gz ok

  CPAN.pm: Going to build H/HA/HAYASHI/Term-ReadLine-Gnu-1.20.tar.gz

Found `/usr/lib/libtermcap.dylib'.
llvm-gcc-4.2  -arch x86_64 -arch i386 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -I/usr/local/include -DHAVE_STRING_H rlver.c -o rlver   -arch x86_64 -arch i386 -fstack-protector -L/usr/local/lib -lreadline -ltermcap
ld: warning: ld: warning: ignoring file /Users/.../sage-5.8.beta1/local/lib/libtermcap.a, file was built for archive which is not the architecture being linked (i386): /Users/.../sage-5.8.beta1/local/lib/libtermcap.aignoring file /Users/.../sage-5.8.beta1/local/lib/libreadline.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Users/.../sage-5.8.beta1/local/lib/libreadline.dylib

Undefined symbols for architecture i386:
  "_rl_library_version", referenced from:
      _main in cckKsg6f.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/k8/nj0z1bkd11dcs1v5hbh_tknc92p43w/T//cc1NJ0c0.out (No such file or directory)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Could not compile rlver.c.

If you have installed the GNU Readline Library (libreadline.{a,so} and
readline/readline.h, etc.) on directories for which your perl is not
configured to search (refer the value of `ccflags' and `libpath' in
the output of `perl -V'), specify the paths as follows;

    perl Makefile.PL --includedir=/yourdir/include --libdir=/yourdir/lib
or
    perl Makefile.PL --prefix=/yourdir

Note that the GNU Readline Library version 2.0 and earlier causes error
here.  Update it to version 2.1 and/or later.

Read INSTALL for more details.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Warning: No success on command[/usr/bin/perl Makefile.PL]
'YAML' not installed, will not store persistent state
  HAYASHI/Term-ReadLine-Gnu-1.20.tar.gz
  /usr/bin/perl Makefile.PL -- NOT OK
Running make test
  Make had some problems, won't test
Running make install
  Make had some problems, won't install

I think we need to pass the Sage gcc to this. But it's not clear to me from reading some stuff online whether one would even be able to use the Sage gcc with the local perl (compiled, perhaps, by llvm-gcc...). I tried a lot of stuff but I have a feeling that there is no real solution to this.

tkluck commented 11 years ago

comment:17

Have you tried installing that package from CPAN but from outside of the sage shell? Since we use the system's perl, we should probably also install the packages system-wide. On my Ubuntu machine, the configure script complains about the following missing perl modules:

    XML::Writer  XML::LibXML  XML::LibXSLT Term::ReadLine::Gnu

Since polymake remains an optional package, maybe we can just require users to install these from CPAN themselves? I don't feel like adding sage's own personal perl package manager to the spkg system...

As for the ReadLine package, we may not need it if Sage is going to use polymake through its shared library interface, like what I'm trying to do in #14116. My guess is that polymake only uses ReadLine for its command line interface.

kcrisman commented 11 years ago

comment:18

Have you tried installing that package from CPAN but from outside of the sage shell?

Yes. That's the error message. But that's not the issue.

Since polymake remains an optional package, maybe we can just require users to install these from CPAN themselves? I don't feel like adding sage's own personal perl package manager to the spkg system...

The problem is that the default libreadline on Mac is not GNU readline. See here, for example. I'm just wondering what the "right" solution is; ideally, we would use Sage's libreadline (if it were possible to pass this to the Perl package) but we need to install the Perl module before we do the Sage package compilation... chicken and the egg. I'm trying some stuff and will report back.

As for the ReadLine package, we may not need it if Sage is going to use polymake through its shared library interface, like what I'm trying to do in #14116. My guess is that polymake only uses ReadLine for its command line interface.

Probably true. But how do we disable it needing that - is there yet another configure option that would disable it? Anyway, for this ticket it would be helpful to find a way to do it with readline.

tkluck commented 11 years ago

comment:19

Replying to @kcrisman:

Anyway, for this ticket it would be helpful to find a way to do it with readline.

I think that Sage's polymake interface through pexpect (on the sage side) and readline (on the polymake side) is currently broken anyway, independent of this upgrade. IIRC, the current polymake package fails to install in recent versions of sage. And on the other hand, the new version of polymake from this ticket doesn't work with the current library code: it outputs copyright info to stderr, which sage interprets as an error having occurred.

So in fact, I'm not sure if we really need to try to make the pexpect/readline interface work, when there's already efforts underway for replacing it by the shared library interface from the new version of polymake. That is to say, I'm not inclined to spend much time on that.

(This is an example of a ticket needing a simultaneous change in a package and in the sage library code. For these tickets, the transition to a unified repository is very useful.)

But how do we disable it needing that - is there yet another configure option that would disable it?

The polymake configure script will only warn about cpan packages not being available, and it will still install without them. As long as we don't use the readline features, and as long as we ask the user to install those other packages from cpan, there is no problem. That is, if those other packages install correctly on MacOS. Do they?

kcrisman commented 11 years ago

comment:20

So in fact, I'm not sure if we really need to try to make the pexpect/readline interface work, when there's already efforts underway for replacing it by the shared library interface from the new version of polymake. That is to say, I'm not inclined to spend much time on that.

That's fine with me, but it looked like you didn't have #14116 ready to test yet (as in having an spkg). And I'm not sure it's possible to build polymake without the readline. I couldn't find anything about that, anyway; they do have options for building without the Java viewers, but not without the command line at all.

Wait, I now understand what you are saying - there will be an error and the command line version won't run (see, in fact, my comment:16) but maybe the library interface will still work. Intriguing idea. I'll check it out.

But how do we disable it needing that - is there yet another configure option that would disable it?

The polymake configure script will only warn about cpan packages not being available, and it will still install without them. As long as we don't use the readline features, and as long as we ask the user to install those other packages from cpan, there is no problem. That is, if those other packages install correctly on MacOS. Do they?

There was only one other Perl package I had to install, and

sudo perl -MCPAN -e 'install XML::LibXSLT'

went fine (the sudo was necessary, though).

kcrisman commented 11 years ago

comment:21

Don't forget that whatever you do here will require a slight change in spkg-install

./configure --without-java --with-fink=no --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL" --with-readline="$SAGE_LOCAL" --with-mpfr="$SAGE_LOCAL"

I'm going to look at #14116 now, I'm done with this ticket for today :)

kcrisman commented 9 years ago

comment:27

D'oh! The package link is broken! Timo, if you see this, please let us know where we can find it, there are a few places online we can host such things.

tkluck commented 9 years ago

Description changed:

--- 
+++ 
@@ -8,4 +8,4 @@

 Here's the link to the new package:

-http://infty.nl/misc/polymake-2.12.spkg
+http://www.infty.nl/misc/polymake-2.12.spkg

tkluck commented 9 years ago

comment:29

Sorry! The link works when replacing http://infty.nl by http://www.infty.nl. I updated the description.

The package can be found at: http://www.infty.nl/misc/polymake-2.12.spkg

kcrisman commented 9 years ago

comment:30

Trying on Mac again. First, same problem, so let's definitely change to

./configure --prefix="$SAGE_LOCAL" --with-boost="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL" --without-java --with-fink=no

Probably at least sudo perl -MCPAN -e 'install XML::LibXSLT' is still necessary, though this is the same computer I used before so I don't think it will complain yet.

Other comments:

polymake is now at version 2.13
For OS X 10.8 and 10.9 (newer than mine) claims to have perl bundles to solve some of these problems, though I'm not precisely sure what they entail. They have something for 10.7 for polymake 2.12 as well.

However, perhaps all of this is superseded by the branch and new-style spkg at #14116?

kcrisman commented 9 years ago

comment:31

Having had some success with #14116, I'm very much thinking this is a duplicate.

kcrisman commented 9 years ago

Changed dependencies from #13767 to none

kcrisman commented 9 years ago

Changed author from Timo Kluck to none

kcrisman commented 9 years ago

comment:32

Yes, but setting to sage-pending in case this old-style spkg is updated with the right config. The one at #5488 is definitely superseded by this, anyway.

kcrisman commented 9 years ago

comment:33

Things are looking good at #14116, so likely this will indeed end up closed - stay tuned.