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.