Closed vbraun closed 12 years ago
Description changed:
---
+++
@@ -2,4 +2,5 @@
The new spkg builds PALP multiple times with different values for the maximal dimension `POLY_Dmax`. This is useful because we want high dimension limits to be general but some features only work with particular low dimension limits, for example the 4-d Hodge database requires PALP to be built with `PALP_Dmax=4`.
-
+Updated spkg is here:
+http://www.stp.dias.ie/~vbraun/Sage/spkg/palp-2.0.p0.spkg
Reviewer: Andrey Novoseltsev
Looks good to me and seems to work fine! Just a couple of comments on spkg-install:
Line 3: "the the"
Lines 34 and 45: since there is now mori.x application, perhaps it should be added?
I don't foresee any use of mori.x in Sage, what we already have in the toric geometry package is more general (e.g. the fan need not be simplicial to compute the Kahler cone, plus no dimension/number of ray restrictions). Max's students implemented a expect interface to Singular in C to compute the Stanley-Reisner ideal, but Sage has libSingular. Though I guess we might just as well install it since it is built by default. I've updated the spkg accordingly.
Could this have caused
The following tests failed:
sage -t -force_lib devel/sage/sage/geometry/lattice_polytope.py # 94 doctests failed
sage -t -force_lib devel/sage/sage/schemes/generic/fano_toric_variety.py # 18 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1317.4 seconds
Just a few examples of the failures:
sage -t -force_lib devel/sage/sage/geometry/lattice_polytope.py
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/devel/sage-xyzzy/sage/geometry/lattice_polytope.py", line 4347:
sage: print s
Expected:
M:27 8 N:7 6 codim=2 #part=5
P:0 V:2 4 5 0sec 0cpu
P:2 V:3 4 5 0sec 0cpu
P:3 V:4 5 0sec 0cpu
np=3 d:1 p:1 0sec 0cpu
Got:
M:27 8 N:7 6 codim=2 #part=0
np=0 d:0 p:0 0sec 0cpu
<BLANKLINE>
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/devel/sage-xyzzy/sage/geometry/lattice_polytope.py", line 4353:
sage: lattice_polytope._read_nef_x_partitions(s)
Expected:
[[2, 4, 5], [3, 4, 5], [4, 5]]
Got:
[]
**********************************************************************
sage -t -force_lib devel/sage/sage/schemes/generic/fano_toric_variety.py
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/devel/sage-xyzzy/sage/schemes/generic/fano_toric_variety.py", line 1098:
sage: np = p.nef_partitions()[1]
Exception raised:
Traceback (most recent call last):
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_13[3]>", line 1, in <module>
np = p.nef_partitions()[Integer(1)]###line 1098:
sage: np = p.nef_partitions()[1]
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/lib/python/site-packages/sage/geometry/lattice_polytope.py", line 2128, in nef_partitions
self._read_nef_partitions(self.nef_x(keys))
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/lib/python/site-packages/sage/geometry/lattice_polytope.py", line 2162, in nef_x
return self._palp("nef.x -f " + keys)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/lib/python/site-packages/sage/geometry/lattice_polytope.py", line 991, in _palp
fn = _palp(command, [self], reduce_dimension)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/local/lib/python/site-packages/sage/geometry/lattice_polytope.py", line 4322, in _palp
+ "\nOutput:\n%s") % (command, err)
RuntimeError: Error executing "nef.x -f -N -V -D -P -p" for a polytope sequence!
Output:
nef.x: Nefpart.c:551: Initial_Conditions: Assertion `(_Y[0].X[0][0] == 1) || (_Y[0].X[0][0] == -1)' failed.
Aborted
**********************************************************************
I have done the following: unpack sage-4.8.alpha1.tar, remove old PALP package from standard and add Volker's new one. Then run make ptestlong and I didn't see any failures...
In particular the very first error shows that PALP just does not work correctly anymore, i.e. it is not some kind of an ordering/parsing issue.
I have just rerun tests on lattice_polytope
separately - they still pass.
Can it be some kind of a platform issue that prevents new version of PALP from building? The package install script is quite simple and seems to do all it is trying to do just fine.
Jeroen, this is again on sage.math, right? It does work for me on sage.math:
vbraun@sage:~/Sage/sage-4.8.alpha2$ ./sage -t --long devel/sage/sage/geometry/lattice_polytope.py
sage -t --long "devel/sage/sage/geometry/lattice_polytope.py"
[52.5 s]
vbraun@sage:~/Sage/sage-4.8.alpha2$ ./sage -t --long devel/sage/sage/schemes/generic/fano_toric_variety.py
sage -t --long "devel/sage/sage/schemes/generic/fano_toric_variety.py"
[22.9 s]
Given the mysterious (at least to me) build failure for R, did you get any other strange errors while testing? It could be a hardware problem. But if R and PALP are the only two issues then its unlikely that I would be on both tickets....
Replying to @vbraun:
Jeroen, this is again on sage.math, right?
Yes.
Given the mysterious (at least to me) build failure for R, did you get any other strange errors while testing?
No, only the lattice polytope stuff. Of course it could be a build failure for PALP, that PALP somehow miscompiled.
It could be a hardware problem.
Then other people on sage.math would find problems.
But if R and PALP are the only two issues then its unlikely that I would be on both tickets....
??? I don't understand what you mean here.
But yes, R and PALP were the only two issues.
I am now building sage-4.8.alpha2 with only the new R and PALP packages, no other changes. I will report back later.
Replying to @jdemeyer:
I am now building sage-4.8.alpha2 with only the new R and PALP packages, no other changes.
It works now...
However, the new PALP adds many files in SAGE_ROOT/local/bin
which should be added to .hgignore
:
? class-11d.x
? class-4d.x
? class-5d.x
? class-6d.x
? cws-11d.x
? cws-4d.x
? cws-5d.x
? cws-6d.x
? mori-11d.x
? mori-4d.x
? mori-5d.x
? mori-6d.x
? mori.x
? nef-11d.x
? nef-4d.x
? nef-5d.x
? nef-6d.x
? poly-11d.x
? poly-4d.x
? poly-5d.x
? poly-6d.x
Also, could you change the following permissions in the spkg (they would better be 0755):
445673875 0 drwx------ 4 jdemeyer jdemeyer 140 Nov 20 11:02 .
445673877 0 drwx------ 2 jdemeyer jdemeyer 600 Jul 1 17:25 ./src
Initial patch, for SAGE_LOCAL/bin
Attachment: trac-12055-SAGELOCAL_BIN.patch.gz
The permissions are fine here:
[vbraun@volker-desktop r-2.14.0.p0]$ ll
total 164
drwxr-xr-x. 2 vbraun vbraun 4096 Nov 19 22:09 patches
-rw-r--r--. 1 vbraun vbraun 135549 Dec 27 2009 rpy2-2.0.8.spkg
-rwxr-xr-x. 1 vbraun vbraun 220 Jan 26 2008 spkg-check
-rwxr-xr-x. 1 vbraun vbraun 7097 Sep 25 2010 spkg-install
-rw-r--r--. 1 vbraun vbraun 4720 Nov 23 11:32 SPKG.txt
drwxr-xr-x. 10 vbraun vbraun 4096 Oct 31 08:08 src
[vbraun@volker-desktop r-2.14.0.p0]$ umask
0002
Jeroen, can you check your umask / mount point options?
Description changed:
---
+++
@@ -4,3 +4,5 @@
Updated spkg is here:
http://www.stp.dias.ie/~vbraun/Sage/spkg/palp-2.0.p0.spkg
+
+Apply trac-12055-SAGELOCAL_BIN.patch to the SAGE_LOCAL/bin repository.
This is about PALP, not R.
Uh-oh too early in the morning %-)
Fixed in the new spkg (same location)
positive review
Merged: sage-4.8.alpha3
Changed reviewer from Andrey Novoseltsev to Andrey Novoseltsev, Jeroen Demeyer
Changed merged from sage-4.8.alpha3 to none
I think there is something wrong with the PALP spkg. I tried merging sage-4.8.alpha3 again with this ticket. Even though it might have succeeded a few times, I now got essentially the same error as before:
sage -t -force_lib devel/sage/sage/geometry/lattice_polytope.py
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/devel/sage-main/sage/geometry/lattice_polytope.py", line 4347:
sage: print s
Expected:
M:27 8 N:7 6 codim=2 #part=5
P:0 V:2 4 5 0sec 0cpu
P:2 V:3 4 5 0sec 0cpu
P:3 V:4 5 0sec 0cpu
np=3 d:1 p:1 0sec 0cpu
Got:
M:27 8 N:7 6 codim=2 #part=0
np=0 d:0 p:0 0sec 0cpu
<BLANKLINE>
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.8.alpha3/devel/sage-main/sage/geometry/lattice_polytope.py", line 4353:
sage: lattice_polytope._read_nef_x_partitions(s)
Expected:
[[2, 4, 5], [3, 4, 5], [4, 5]]
Got:
[]
**********************************************************************
...
The following tests failed:
sage -t -force_lib devel/sage/sage/geometry/lattice_polytope.py # 94 doctests failed
sage -t -force_lib devel/sage/sage/schemes/generic/fano_toric_variety.py # 18 doctests failed
----------------------------------------------------------------------
I'm attaching my palp log file, even though I don't see anything suspicious.
Jeroen, are you using a different compiler than /usr/bin/gcc? Or perhaps some funky CFLAGS? Our binaries are not the same on sage.math, so something is fishy here:
vbraun@sage:~/Sage$ ll /mnt/usb1/scratch/jdemeyer/sage*/local/bin/nef-6d.x
-rwxr-xr-x 1 jdemeyer jdemeyer 1112924 2011-11-29 10:23 /mnt/usb1/scratch/jdemeyer/sage-4.8.alpha3_PALP_failure/local/bin/nef-6d.x
vbraun@sage:~/Sage$ ll /home/vbraun/Sage/sage-4.8.alpha2/local/bin/nef-6d.x
-rwxr-xr-x 1 vbraun vbraun 1016813 2011-11-29 11:22 /home/vbraun/Sage/sage-4.8.alpha2/local/bin/nef-6d.x
When I run my version in valgrind I get no errors, but when I run your version in valgrind I get lots of uninitialized variable errors:
vbraun@sage:~/Sage$ ~/Sage/valgrind/valgrind-3.7.0/vg-in-place /mnt/usb1/scratch/jdemeyer/sage-4.8.alpha3_PALP_failure/local/bin/nef-6d.x -N -f -p < /tmp/palp_in
==9884== Memcheck, a memory error detector
==9884== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==9884== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9884== Command: /mnt/usb1/scratch/jdemeyer/sage-4.8.alpha3_PALP_failure/local/bin/nef-6d.x -N -f -p
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x43A0A6: part_nef (Nefpart.c:569)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x40EE3A: GLZ_Make_Trian_NF (Polynf.c:142)
==9884== by 0x439CF1: part_nef (Nefpart.c:818)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x40EE87: GLZ_Make_Trian_NF (Polynf.c:145)
==9884== by 0x439CF1: part_nef (Nefpart.c:818)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x40F0A7: GLZ_Make_Trian_NF (Polynf.c:159)
==9884== by 0x439CF1: part_nef (Nefpart.c:818)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x40F300: GLZ_Make_Trian_NF (Polynf.c:166)
==9884== by 0x439CF1: part_nef (Nefpart.c:818)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x4389A1: Initial_Conditions (Nefpart.c:551)
==9884== by 0x439D88: part_nef (Nefpart.c:820)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x4389FC: Initial_Conditions (Nefpart.c:551)
==9884== by 0x439D88: part_nef (Nefpart.c:820)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x439143: Select_Sv (Nefpart.c:733)
==9884== by 0x439DD9: part_nef (Nefpart.c:821)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
==9884== Conditional jump or move depends on uninitialised value(s)
==9884== at 0x4391C9: Select_Sv (Nefpart.c:469)
==9884== by 0x439DD9: part_nef (Nefpart.c:821)
==9884== by 0x43557A: Make_E_Poly (E_Poly.c:1266)
==9884== by 0x402AEF: main (nef.c:294)
==9884==
M:27 8 N:7 6 codim=2 #part=0
np=0 d:0 p:0 0sec 0cpu
==9884==
==9884== HEAP SUMMARY:
==9884== in use at exit: 0 bytes in 0 blocks
==9884== total heap usage: 42 allocs, 42 frees, 543,330,152 bytes allocated
==9884==
==9884== All heap blocks were freed -- no leaks are possible
==9884==
==9884== For counts of detected and suppressed errors, rerun with: -v
==9884== Use --track-origins=yes to see where uninitialised values come from
==9884== ERROR SUMMARY: 1367 errors from 9 contexts (suppressed: 2 from 2)
Replying to @vbraun:
Jeroen, are you using a different compiler than /usr/bin/gcc?
Yes, I am using gcc 4.5.1 (compiled myself, /home/jdemeyer/local/bin/gcc
). Default CFLAGS
.
But I also realized that I have compiled and tested PALP successfully before, so the problem is not always reproducible. Could there be a race condition in the spkg-install
or Makefile
?
Actually, never mind the gcc version, I did use gcc 4.2.4, see also the log I posted. My merger script uses a default PATH
.
This is interesting: when built in parallel, I do not get the error anymore. So it is some kind of reverse race condition.
Could you try simply installing palp serially from a working Sage:
./sage -f spkg/standard/palp-2.0.p0.spkg
And then doing
./sage -t devel/sage/sage/geometry/lattice_polytope.py
Something else: your make
in spkg-install
should probably be $MAKE
.
I think I got it: Sage.math runs ext3 which has a 1-second timestamp granularity. My new does compile - monkeypatch - recompile in a loop. If you have a reasonably fast disk like /mnt/usb1/scratch then you can do the patch step in less than a second, so make fails to see that anything changed. Whereas I compiled sage on /home which is might be a higher-latency disk since its shared with lots of people. Or use ext4 with nanosecond timestamps on my own computers.
I've replaced the palp spkg with a new version that does a make clean in-between each recompile loop. I'm pretty confident that it fixes the problem. Can you try it?
I also just tripped over the fact that sage -f will happily use the old cached spkg, so make sure to delete the cached old version.
I'm wondering about the portability of "install", the previous version used "cp". I think it would be safer to install using "cp -p".
Well "install" works on Sparc solaris with is generally the yardstick for how weird systems we support ;-) I think that install is a better choice because
Replying to @vbraun:
Well "install" works on Sparc solaris with is generally the yardstick for how weird systems we support ;-)
It actually doesn't on hawk
. True, the command install
exists, but it certainly does no do what you want:
uname -a:
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5.0/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.5.0/configure --prefix=/usr/local/gcc-4.5.0 --build=i386-pc-solaris2.10 --enable-languages=c,c++,fortran --with-
gmp=/usr/local/gcc-4.5.0 --with-mpfr=/usr/local/gcc-4.5.0 --disable-nls --enable-checking=release --enable-werror=no --enable-multilib -wi
th-system-zlib --enable-bootstrap --with-gnu-as --with-as=/usr/local/binutils-2.20/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 4.5.0 (GCC)
****************************************************
Building PALP optimized for 4 dimensions
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o poly.o poly.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Coord.o Coord.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Rat.o Rat.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Vertex.o Vertex.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Polynf.o Polynf.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o LG.o LG.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o class.o class.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Subpoly.o Subpoly.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Subadd.o Subadd.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Subdb.o Subdb.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o cws.o cws.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o nef.o nef.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o E_Poly.o E_Poly.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Nefpart.o Nefpart.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o mori.o mori.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o MoriCone.o MoriCone.c
MoriCone.c: In function 'Compatible_Tri':
MoriCone.c:938:76: warning: unused parameter 'p'
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o SingularInput.o SingularInput.c
Subadd.c: In function 'Add_Polya_2_Polyi':
Subadd.c:1111:31: warning: 'vA' may be used uninitialized in this function
Subadd.c:1111:35: warning: 'nuA' may be used uninitialized in this function
MoriCone.c: In function 'Triang3dSFan':
MoriCone.c:666:25: warning: 'k' may be used uninitialized in this function
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o poly.x poly.o Coord.o Rat.o Vertex.o Polynf.o LG.o
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o class.x class.o Coord.o Rat.o Vertex.o Polynf.o Subpoly.o Subadd.o Subdb
.o
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o cws.x cws.o Coord.o Rat.o Vertex.o Polynf.o LG.o
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o nef.x nef.o Coord.o Rat.o Vertex.o Polynf.o E_Poly.o Nefpart.o LG.o
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o mori.x mori.o Coord.o Rat.o Vertex.o Polynf.o MoriCone.o SingularInput.o
LG.o
find: stat() error /export/home/buildbot/sage-4.8.alpha2/local/bin/poly-4d.x: No such file or directory
find: cannot read dir /etc/flash/preexit: Permission denied
find: cannot read dir /etc/flash/precreation: Permission denied
find: cannot read dir /etc/flash/postcreation: Permission denied
find: cannot read dir /etc/sfw/openssl/private: Permission denied
find: cannot read dir /etc/openssl/private: Permission denied
find: cannot read dir /etc/inet/secret: Permission denied
find: cycle detected for /lib/secure/32/
find: cycle detected for /lib/32/
find: cycle detected for /lib/crypto/32/
find: cycle detected for /usr/lib/lwp/32/
find: cycle detected for /usr/lib/32/
find: cycle detected for /usr/lib/link_audit/32/
find: cycle detected for /usr/lib/elfedit/32/
find: cycle detected for /usr/lib/locale/en_US.UTF-8/32/
find: cycle detected for /usr/lib/locale/en_US.UTF-8/LC_CTYPE/32/
find: cycle detected for /usr/lib/locale/en_US.UTF-8/LO_LTYPE/32/
find: cycle detected for /usr/lib/secure/32/
install: poly.x was not found anywhere!
Error installing PALP.
Awesome! Solaris strikes again...
I switched the spkg back to cp -p.
Not sure why the need for $MV
, $CP
and the likes (who's idea was that?), but positive_review.
Merged: sage-4.8.alpha3
On OS X 10.6:
Host system
uname -a:
Darwin bsd.math.washington.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
****************************************************
Building PALP optimized for 4 dimensions
make[2]: warning: -jN forced in submake: disabling jobserver mode.
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o poly.o poly.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Coord.o Coord.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Rat.o Rat.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Vertex.o Vertex.c
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c -o Polynf.o Polynf.c
Polynf.c: In function 'Fano5d':
Polynf.c:2444: error: nested functions are disabled, use -fnested-functions to re-enable
make[2]: *** [Polynf.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Error building PALP.
See also http://lists.apple.com/archives/Xcode-users/2005/Nov/msg00274.html
I've asked upstream whether they can get rid of the use of nested functions, I think it is used only once. Really no need to make it non-portable just for that. In the meantime, I've updated the palp spkg with a special case for UNAME=Darwin
to enable -fnested-functions
on OSX. I tested the new spkg on bsd.math and it compiles fine.
Changed merged from sage-4.8.alpha3 to none
I see in the spkg you patched "Polynf.c". But please use patch
for patching instead of cp
.
Harald Skarke told me that the problematic function is actually unused, so we can just remove it. I've updated the spkg with this alternate fix, so now it should not rely on any GNU C extension any more.
I thought this would fix it but unfortunately nested functions are used elsewhere, too. I'm waiting for Harald to get back to me...
I got the fix from upstream and it does compile on OSX now without problems.
Volker, if you're adding new patches, please add only the .patch file and use patch
in spkg-install
(unless you have a good reason not to do so).
Also, it would be nice to put the ticket number (#12055) in the SPKG.txt
changelog.
Upstream gave me the files as they are, so I would argue that its preferable to just copy them in this case than to create a patch between different upstream versions. Presumably they will be in the next release in this form.
I've added the ticket reference to the SPKG.txt, the updated package is at the same location.
The upstream patched files have one blank line between every source code line. Are you sure this is intentional and not a consequence of some bad CR/LF-related conversion?
I'm pretty sure this is not intentional :-) But since it is C source code extra whitespace is irrelevant.
I got the files sent again, this time without the CR/LF problem. Updated spkg at the same location.
Changed reviewer from Andrey Novoseltsev, Jeroen Demeyer to Andrey Novoseltsev, Jeroen Demeyer, R. Andrew Ohana
This works well for me
Superseded by #7071 (which provides palp-2.0.p1.spkg)
This ticket is about upgrading to PALP-2.0.
The new spkg builds PALP multiple times with different values for the maximal dimension
POLY_Dmax
. This is useful because we want high dimension limits to be general but some features only work with particular low dimension limits, for example the 4-d Hodge database requires PALP to be built withPALP_Dmax=4
.spkg superseded by #7071 (which provides palp-2.0.p1.spkg)
Apply attachment: trac-12055-SAGELOCAL_BIN.patch to the SAGE_LOCAL/bin repository.
CC: @novoselt @kiwifb
Component: algebraic geometry
Author: Volker Braun
Reviewer: Andrey Novoseltsev, Jeroen Demeyer, R. Andrew Ohana
Merged: sage-5.0.beta7
Issue created by migration from https://trac.sagemath.org/ticket/12055