Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Discussions on installation issues go here.
mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 29 Jun 2016, 21:19

To install polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 (this is within Sage), I had to apply a patch to get rid of all "-arch" flags; see https://github.com/mkoeppe/polymake/tree/sage-package
This is to fix errors that can be seen on https://trac.sagemath.org/ticket/20892#comment:6

User avatar
joswig
Main Author
Posts: 280
Joined: 24 Dec 2010, 11:10

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby joswig » 15 Jul 2016, 16:50

It seems that you picked the "minimal" tar ball. Can you please confirm?

The actual use of this install (in a standalone kind of way) is not supported. The reason is that it comes with neither bliss nor nauty. At least one of them is required. This minimal tar ball is meant for packaging only (for distros where bliss or nauty comes from elsewhere).

However, I agree it is a bug that the configuration does not properly catch this error (and warn the user). Will be fixed soon. Please choose other tar balls.

mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 15 Jul 2016, 16:58

It seems that you picked the "minimal" tar ball. Can you please confirm?
Yes.
The actual use of this install (in a standalone kind of way) is not supported. The reason is that it comes with neither bliss nor nauty. At least one of them is required. This minimal tar ball is meant for packaging only (for distros where bliss or nauty comes from elsewhere).
Well, SageMath is a distribution, so to say; see here: https://github.com/sagemath/sage/tree/master/build/pkgs
It already comes with packages for most of the software that you bundle with polymake.
However, I agree it is a bug that the configuration does not properly catch this error (and warn the user). Will be fixed soon. Please choose other tar balls.
OK, will try; but I'd be surprised if the particular error that I reported here has anything to do with minimal/full.

mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 15 Jul 2016, 17:10

This minimal tar ball is meant for packaging only (for distros where bliss or nauty comes from elsewhere).
Just another quick note. The "minimal tarball" omits not only the nauty sources, but also polymake's interface to it. So this is probably something worth addressing when you prepare the next minimal tarball for distros' convenience.

blorenz
Developer
Posts: 139
Joined: 10 Jan 2011, 17:21

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby blorenz » 21 Jul 2016, 11:12

To install polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 (this is within Sage), I had to apply a patch to get rid of all "-arch" flags; see https://github.com/mkoeppe/polymake/tree/sage-package
This is to fix errors that can be seen on https://trac.sagemath.org/ticket/20892#comment:6
Thanks for the report, we have looked into this configuration issue but couldn't reproduce it so far. Since this a rather special setup we have not included this change for the upcoming bugfix release 3.0r2.

We have some restructuring planned regarding the configuration on OS X for the next proper release and I have added this to the ticket to make sure this gets addressed. In the meantime would you be so kind to provide the output of the following commands (with the perl and gcc versions that had these issues):

Code: Select all

perl -MExtUtils::Embed -e ccopts perl -MExtUtils::Embed -e ldopts gcc -v lipo -info /sw/lib/libgmp.dylib
Just another quick note. The "minimal tarball" omits not only the nauty sources, but also polymake's interface to it. So this is probably something worth addressing when you prepare the next minimal tarball for distros' convenience.
Our interface to nauty is based on compiling a static library out of some of the nauty source-files with our own Makefile (and options). Hence, there is currently no point in packaging just this interface.

mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 21 Jul 2016, 14:00

To install polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 (this is within Sage), I had to apply a patch to get rid of all "-arch" flags; see https://github.com/mkoeppe/polymake/tree/sage-package
This is to fix errors that can be seen on https://trac.sagemath.org/ticket/20892#comment:6
Thanks for the report, we have looked into this configuration issue but couldn't reproduce it so far.
Here's by the way the Sage ticket. https://trac.sagemath.org/ticket/20892
Can just build to reproduce.
Since this a rather special setup we have not included this change for the upcoming bugfix release 3.0r2.
;)
We have some restructuring planned regarding the configuration on OS X for the next proper release and I have added this to the ticket to make sure this gets addressed. In the meantime would you be so kind to provide the output of the following commands (with the perl and gcc versions that had these issues):

Code: Select all

perl -MExtUtils::Embed -e ccopts perl -MExtUtils::Embed -e ldopts gcc -v lipo -info /sw/lib/libgmp.dylib
Here you go:

Code: Select all

(sage-sh) mkoeppe@83add760:~$ perl -MExtUtils::Embed -e ccopts -arch i386 -arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE (sage-sh) mkoeppe@83add760:~$ perl -MExtUtils::Embed -e ldopts -arch i386 -arch x86_64 -fstack-protector -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl (sage-sh) mkoeppe@83add760:~$ gcc -v Using built-in specs. COLLECT_GCC=/Users/mkoeppe/cvs/sage/local/bin/gcc COLLECT_LTO_WRAPPER=/Users/mkoeppe/cvs/sage/local/libexec/gcc/x86_64-apple-darwin15.2.0/4.9.2/lto-wrapper Target: x86_64-apple-darwin15.2.0 Configured with: ../src/configure --prefix=/Users/mkoeppe/cvs/sage/local --with-local-prefix=/Users/mkoeppe/cvs/sage/local --with-gmp=/Users/mkoeppe/cvs/sage/local --with-mpfr=/Users/mkoeppe/cvs/sage/local --with-mpc=/Users/mkoeppe/cvs/sage/local --with-system-zlib --disable-multilib --disable-nls --enable-languages=c,c++,fortran --disable-libitm --with-build-config=bootstrap-debug --without-isl --without-cloog Thread model: posix gcc version 4.9.2 (GCC) (sage-sh) mkoeppe@83add760:~$ lipo -info /sw/lib/libgmp.dylib Non-fat file: /sw/lib/libgmp.dylib is architecture: x86_64
Just another quick note. The "minimal tarball" omits not only the nauty sources, but also polymake's interface to it. So this is probably something worth addressing when you prepare the next minimal tarball for distros' convenience.
Our interface to nauty is based on compiling a static library out of some of the nauty source-files with our own Makefile (and options). Hence, there is currently no point in packaging just this interface.
No, you misunderstand. Distributions will have to patch your build system anyway. So they can patch whatever you do regarding nauty to make it work. With the status quo, a distribution that wants to make nauty work would have to re-add the nauty interface that you removed.

blorenz
Developer
Posts: 139
Joined: 10 Jan 2011, 17:21

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby blorenz » 25 Jul 2016, 14:31

We have published release 3.0r2 now.
The minimal tarball now includes the nauty interface (without the nauty sources) along with a small configuration script which allows specifying a nauty source directory via the configure command (--with-nauty-src).

Just for clarification:
The "rather special setup" was directed at the mix of using gcc from sage, perl from OS X and several packages via fink.
The main reason for not including any changes to the arch flags in this release is to avoid breaking other configurations in a bugfix-release, as the OS X configuration is already quite fragile.

Thanks for posting the output of these commands.

mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 25 Jul 2016, 18:32

We have published release 3.0r2 now.
Thanks, it seems to work well within Sage. https://trac.sagemath.org/ticket/20892#comment:72
The minimal tarball now includes the nauty interface (without the nauty sources) along with a small configuration script which allows specifying a nauty source directory via the configure command (--with-nauty-src).
OK, I'll look into what can be done with it.
The "rather special setup" was directed at the mix of using gcc from sage, perl from OS X and several packages via fink.
The main reason for not including any changes to the arch flags in this release is to avoid breaking other configurations in a bugfix-release, as the OS X configuration is already quite fragile.

Thanks for posting the output of these commands.
Right, just another clarification, Sage does not use anything from fink, and in fact I configure Polymake using --without-fink.
You asked for the shared library information of the Fink libgmp, but what's relevant in my case is actually the following -- which however gives the same results.

Code: Select all

lipo -info $SAGE_LOCAL/lib/libgmp* input file /Users/mkoeppe/cvs/sage/local/lib/libgmp.a is not a fat file input file /Users/mkoeppe/cvs/sage/local/lib/libgmpxx.a is not a fat file Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmp.16.dylib is architecture: x86_64 Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmp.a is architecture: x86_64 Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmp.dylib is architecture: x86_64 Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmpxx.8.dylib is architecture: x86_64 Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmpxx.a is architecture: x86_64 Non-fat file: /Users/mkoeppe/cvs/sage/local/lib/libgmpxx.dylib is architecture: x86_64
So what's happening here is simply that GMP and other libraries are built for one architecture only, whereas "perl -MExtUtils::Embed -e ccflags" gives flags that build for two architectures at the time. Probably not so uncommon and worth detecting in your configure script. But in any case we have a working workaround now for Sage, so no immediate action is necessary. Thanks for addressing the other suggestions in the latest release.

mkoeppe
Posts: 17
Joined: 27 Jun 2016, 19:44

Re: Installing polymake 3.0r1 from source on Mac OS X using gcc 4.9.2 - patch

Postby mkoeppe » 05 Aug 2016, 18:55

So what's happening here is simply that GMP and other libraries are built for one architecture only, whereas "perl -MExtUtils::Embed -e ccflags" gives flags that build for two architectures at the time.
Just a quick follow-up. I have just found an easier workaround that does not require patching Polymake's configure script any more. It suffices to set the environment variable ARCHFLAGS (for example, to an empty value) when calling configure. (When ARCHFLAGS is unset, ExtUtils::Embed picks up these flags from the Perl installation, which caused the reported problem.)
This is what we now do in the Sage package; see https://trac.sagemath.org/ticket/20892#comment:90


Return to “Installing polymake”