Upgrade PALP

[vbraun]

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 with PALP_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

[vbraun]

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

[novoselt]

Reviewer: Andrey Novoseltsev

[novoselt]

comment:3

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?

[vbraun]

comment:4

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.

[jdemeyer]

comment:6

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

**********************************************************************

[novoselt]

comment:7

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

[novoselt]

comment:8

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.

[vbraun]

comment:9

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

[jdemeyer]

comment:10

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.

[jdemeyer]

comment:11

I am now building sage-4.8.alpha2 with only the new R and PALP packages, no other changes. I will report back later.

[jdemeyer]

comment:12

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

[jdemeyer]

comment:13

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

[vbraun]

Initial patch, for SAGE_LOCAL/bin

[vbraun]

comment:14

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?

[vbraun]

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.

[jdemeyer]

comment:15

This is about PALP, not R.

[vbraun]

comment:16

Uh-oh too early in the morning %-)

Fixed in the new spkg (same location)

[jdemeyer]

comment:17

positive review

[jdemeyer]

Merged: sage-4.8.alpha3

[jdemeyer]

Changed reviewer from Andrey Novoseltsev to Andrey Novoseltsev, Jeroen Demeyer

[jdemeyer]

Changed merged from sage-4.8.alpha3 to none

[jdemeyer]

comment:18

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.

[vbraun]

comment:19

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)

[jdemeyer]

comment:20

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?

[jdemeyer]

comment:21

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.

[jdemeyer]

comment:22

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

[jdemeyer]

comment:23

Something else: your make in spkg-install should probably be $MAKE.

[vbraun]

comment:24

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.

[vbraun]

comment:25

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.

[jdemeyer]

comment:26

I'm wondering about the portability of "install", the previous version used "cp". I think it would be safer to install using "cp -p".

[vbraun]

comment:27

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

• its designed for the job
• cp -p might preserve ACLs or other extended attributes which you don't want (not the GNU coreutils, mind you)
• autotools use it, probably for a reason

[jdemeyer]

comment:28

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.

[vbraun]

comment:29

Awesome! Solaris strikes again...

I switched the spkg back to cp -p.

[jdemeyer]

comment:30

Not sure why the need for $MV, $CP and the likes (who's idea was that?), but positive_review.

[jdemeyer]

Merged: sage-4.8.alpha3

[jdemeyer]

comment:31

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.

[jdemeyer]

comment:32

See also http://lists.apple.com/archives/Xcode-users/2005/Nov/msg00274.html

[vbraun]

comment:33

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.

[jdemeyer]

Changed merged from sage-4.8.alpha3 to none

[jdemeyer]

comment:35

I see in the spkg you patched "Polynf.c". But please use patch for patching instead of cp.

[vbraun]

comment:36

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

[vbraun]

comment:37

I got the fix from upstream and it does compile on OSX now without problems.

[jdemeyer]

comment:38

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.

[vbraun]

comment:39

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.

[jdemeyer]

comment:40

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?

[vbraun]

comment:41

I'm pretty sure this is not intentional :-) But since it is C source code extra whitespace is irrelevant.

[vbraun]

comment:42

I got the files sent again, this time without the CR/LF problem. Updated spkg at the same location.

[ohanar]

Changed reviewer from Andrey Novoseltsev, Jeroen Demeyer to Andrey Novoseltsev, Jeroen Demeyer, R. Andrew Ohana

[ohanar]

comment:43

This works well for me

[vbraun]

comment:44

Superseded by #7071 (which provides palp-2.0.p1.spkg)