Sage: Ticket #11708: maxima doesn't build on Linux ppc64 (silius on skynet)
https://trac.sagemath.org/ticket/11708
<p>
The maxima spkg in sage-4.7.1 fails to build almost instantly with:
</p>
<pre class="wiki">...
;;; Emitting code for UNARY.
Internal or unrecoverable error in:
not a lisp data object
[2: No such file or directory]
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/11708
Trac 1.1.6wasThu, 18 Aug 2011 21:26:11 GMT
https://trac.sagemath.org/ticket/11708#comment:1
https://trac.sagemath.org/ticket/11708#comment:1
<p>
NOTE: A naive attempt with maxima-5.25 fails in exactly the same way.
</p>
TicketleifThu, 18 Aug 2011 21:28:21 GMT
https://trac.sagemath.org/ticket/11708#comment:2
https://trac.sagemath.org/ticket/11708#comment:2
<p>
Nice. I didn't know we have any Linux PPC in our build farm. :)
</p>
TicketkcrismanFri, 19 Aug 2011 01:28:34 GMT
https://trac.sagemath.org/ticket/11708#comment:3
https://trac.sagemath.org/ticket/11708#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:2" title="Comment 2">leif</a>:
</p>
<blockquote class="citation">
<p>
Nice. I didn't know we have any Linux PPC in our build farm. :)
</p>
</blockquote>
<p>
I'll ask about this on the Maxima devel list. Maybe there is some little configuration thing that needs to be set.
</p>
TicketfbisseyFri, 19 Aug 2011 01:44:50 GMT
https://trac.sagemath.org/ticket/11708#comment:4
https://trac.sagemath.org/ticket/11708#comment:4
<p>
Could we see more of that log? And I'd like to see the ecl build log as well if it was possible.
</p>
TicketwasFri, 19 Aug 2011 04:26:25 GMT
https://trac.sagemath.org/ticket/11708#comment:5
https://trac.sagemath.org/ticket/11708#comment:5
<p>
Here's a huge log file
</p>
<blockquote>
<p>
<a class="ext-link" href="http://sage.math.washington.edu/home/wstein/days/32/silius/install.log-20110818.txt"><span class="icon"></span>http://sage.math.washington.edu/home/wstein/days/32/silius/install.log-20110818.txt</a>
</p>
</blockquote>
<p>
It is huge due to building ATLAS, etc. So, just search in it.
</p>
<p>
It looks like maybe *everything* ends up building except Maxima (and Tachyon, which is fixed by another ticket).
</p>
<pre class="wiki">wstein@silius:~/silius/sage-4.7.1> ./sage
----------------------------------------------------------------------
| Sage Version 4.7.1, Release Date: 2011-08-11 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: time n = factorial(10^6)
Time: CPU 0.64 s, Wall: 0.65 s
sage: time n = factorial(10^7)
Time: CPU 11.81 s, Wall: 11.81 s
sage: !uname -a
Linux silius 2.6.32.43-0.4-ppc64 #1 SMP 2011-07-14 14:47:44 +0200 ppc64 ppc64 ppc64 GNU/Linux
</pre>
TicketjhpalmieriFri, 19 Aug 2011 05:28:47 GMT
https://trac.sagemath.org/ticket/11708#comment:6
https://trac.sagemath.org/ticket/11708#comment:6
<p>
Here are log files for ecl and maxima:
</p>
<ul><li><a class="ext-link" href="http://sage.math.washington.edu/home/palmieri/misc/ecl-11.1.1.p1.log"><span class="icon"></span>http://sage.math.washington.edu/home/palmieri/misc/ecl-11.1.1.p1.log</a>
</li><li><a class="ext-link" href="http://sage.math.washington.edu/home/palmieri/misc/maxima-5.23.2.p0.log"><span class="icon"></span>http://sage.math.washington.edu/home/palmieri/misc/maxima-5.23.2.p0.log</a>
</li></ul>
TicketfbisseyFri, 19 Aug 2011 06:42:54 GMT
https://trac.sagemath.org/ticket/11708#comment:7
https://trac.sagemath.org/ticket/11708#comment:7
<p>
Hum... nothing jumps out at me, especially if sage compiled without problems including sage/libs/ecl.pyx. Is there a maxima rpm for sles 11? If so it may be worth looking in the spec file.
</p>
TicketwasFri, 19 Aug 2011 06:54:37 GMT
https://trac.sagemath.org/ticket/11708#comment:8
https://trac.sagemath.org/ticket/11708#comment:8
<p>
Yes, sage/libs/ecl.pyx compiles and passes all tests:
</p>
<pre class="wiki">
wstein@silius:~/silius/sage-4.7.1> ./sage -t devel/sage/sage/libs/ecl.pyx
sage -t "devel/sage/sage/libs/ecl.pyx"
[5.1 s]
----------------------------------------------------------------------
All tests passed!
</pre>
TicketleifFri, 19 Aug 2011 08:32:38 GMT
https://trac.sagemath.org/ticket/11708#comment:9
https://trac.sagemath.org/ticket/11708#comment:9
<p>
Hmmm, there are a couple of warnings already, including
</p>
<pre class="wiki">make[3]: warning: Clock skew detected. Your build may be incomplete.
</pre><p>
but comparing the log to what I have doesn't look very different.
</p>
<p>
How about installing the Maxima spkg with <code>strace -f [...] ./sage -i ...</code>, to see which file <code>ecl</code> apparently doesn't find?
</p>
<p>
It would also perhaps be better to first try to build on a local filesystem (if that wasn't the case, which I assume).
</p>
TicketkcrismanFri, 19 Aug 2011 12:46:19 GMT
https://trac.sagemath.org/ticket/11708#comment:10
https://trac.sagemath.org/ticket/11708#comment:10
<p>
<a class="ext-link" href="http://www.math.utexas.edu/pipermail/maxima/2011/025854.html"><span class="icon"></span>Here</a> is a response from one Maxima developer.
</p>
<pre class="wiki">Maxima probably isn't supported on this platform because probably no
developer normally works on PPC Linux. I might be wrong about that.
On the other hand, I have built maxima just fine using a 64-bit version
of ecl on Linux (x86) and Solaris (sparc). So I would guess that the
problem you are seeing is due to ecl.
</pre><p>
If there are any other responses, I'll update here.
</p>
TicketleifFri, 19 Aug 2011 13:13:20 GMT
https://trac.sagemath.org/ticket/11708#comment:11
https://trac.sagemath.org/ticket/11708#comment:11
<p>
Did Dave ever manage to build Sage in 64-bit mode on <em>SPARC</em>?
</p>
<p>
As far as I know the only big-endians we build / test on are (or just use) 32 bits.
</p>
<p>
I also noticed that silius doesn't have <code>libffi</code>, but I don't think that's relevant here.
</p>
TicketwasFri, 19 Aug 2011 19:23:34 GMT
https://trac.sagemath.org/ticket/11708#comment:12
https://trac.sagemath.org/ticket/11708#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:9" title="Comment 9">leif</a>:
</p>
<blockquote class="citation">
<p>
How about installing the Maxima spkg with <code>strace -f [...] ./sage -i ...</code>, to see which file <code>ecl</code> apparently doesn't find?
</p>
<p>
It would also perhaps be better to first try to build on a local filesystem (if that wasn't the case, which I assume).
</p>
</blockquote>
<p>
Do you want an account on the machine? Then you can try all this and maybe fix the problem!
</p>
<p>
Write me offlist at wstein@… for an account.
</p>
TicketkcrismanFri, 19 Aug 2011 19:27:58 GMT
https://trac.sagemath.org/ticket/11708#comment:13
https://trac.sagemath.org/ticket/11708#comment:13
<p>
By the way, this may be on skynet, but it's not listed at <a class="ext-link" href="http://wiki.sagemath.org/skynet"><span class="icon"></span>the wiki for Sage on skynet</a>.
</p>
TicketwasFri, 19 Aug 2011 19:31:30 GMT
https://trac.sagemath.org/ticket/11708#comment:14
https://trac.sagemath.org/ticket/11708#comment:14
<p>
The machine was added to skynet 2 or 3 days ago.
</p>
<p>
The page <a class="ext-link" href="http://wiki.sagemath.org/skynet"><span class="icon"></span>http://wiki.sagemath.org/skynet</a> is interesting. Note that it is surely out of date, since the compilers are always being updated, operating systems upgraded, etc.
</p>
TicketwasFri, 19 Aug 2011 19:35:21 GMT
https://trac.sagemath.org/ticket/11708#comment:15
https://trac.sagemath.org/ticket/11708#comment:15
<p>
I've added some info about silius stamped "today" to that wiki.
</p>
TicketkcrismanFri, 19 Aug 2011 19:36:47 GMT
https://trac.sagemath.org/ticket/11708#comment:16
https://trac.sagemath.org/ticket/11708#comment:16
<blockquote class="citation">
<p>
The machine was added to skynet 2 or 3 days ago.
</p>
</blockquote>
<p>
Cool.
</p>
<blockquote class="citation">
<p>
The page <a class="ext-link" href="http://wiki.sagemath.org/skynet"><span class="icon"></span>http://wiki.sagemath.org/skynet</a> is interesting. Note that it is surely out of date, since the compilers are always being updated, operating systems upgraded, etc.
</p>
</blockquote>
<p>
John P. reminded me of it on another ticket. Even out-of-date, it seems useful.
</p>
TicketbenjaminfjonesWed, 24 Aug 2011 17:50:00 GMT
https://trac.sagemath.org/ticket/11708#comment:17
https://trac.sagemath.org/ticket/11708#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:9" title="Comment 9">leif</a>:
</p>
<p>
I've been banging my head on this for a while now at Sage Days 32. I've tried the following so far:
</p>
<ul><li>building ECL 11.1.1 independent of Sage and then building Maxima 5.25.0 (latest) on top of that (failed: same "redefining NIL" error that mhansen reported)
</li><li>building latest CVS version of ECL, then Maxima 5.25.0 on top of that (failed: same error as above)
</li><li>making a new .spkg for the latest ECL, then using that to try building the maxima .spkg (failed with "not a lisp data object" error)
</li></ul><p>
</p>
<blockquote class="citation">
<p>
How about installing the Maxima spkg with <code>strace -f [...] ./sage -i ...</code>, to see which file <code>ecl</code> apparently doesn't find?
</p>
</blockquote>
<p>
Just tried this on silius, here is the part of the log just before the error message is printed:
</p>
<pre class="wiki">[pid 13982] write(3, "\tif(!((V1)==(VV[26]))){\n", 24) = 24
[pid 13982] write(3, "\tgoto L21;}\n", 12) = 12
[pid 13982] write(3, "\tT0= LC9next(lex0) "..., 67) = 67
[pid 13982] write(3, "\tcl_env_copy->nvalues=2;\n", 25) = 25
[pid 13982] write(3, "\tcl_env_copy->values[1]=T0;\n", 28) = 28
[pid 13982] write(3, "\tcl_env_copy->values[0]=V1;\n", 28) = 28
[pid 13982] write(3, "\treturn cl_env_copy->values[0];\n", 32) = 32
[pid 13982] write(3, "L21:;\n", 6) = 6
[pid 13982] write(3, "\tif(!((V1)==(VV[30]))){\n", 24) = 24
[pid 13982] write(3, "\tgoto L25;}\n", 12) = 12
[pid 13982] write(3, "\tV1= LC9next(lex0) "..., 67) = 67
[pid 13982] write(2, "\nInternal or unrecoverable error"..., 60) = 60
[pid 12588] <... read resumed> "\nInternal or unrecoverable error"..., 8192) = 60
[pid 12588] write(1, "\nInternal or unrecoverable error"..., 60
Internal or unrecoverable error in:
not a lisp data object
<unfinished ...>
[pid 13982] write(2, " [2: No such file or directory]"..., 33 <unfinished ...>
</pre><p>
The full log is here: <a class="ext-link" href="http://sage.math.washington.edu/home/bjones/strace_maxima.log.gz"><span class="icon"></span>http://sage.math.washington.edu/home/bjones/strace_maxima.log.gz</a> (It is VERY large)
</p>
<blockquote class="citation">
<p>
It would also perhaps be better to first try to build on a local filesystem (if that wasn't the case, which I assume).
</p>
</blockquote>
<p>
I've tried building the maxima .spkg (and Sage overall) both on my NFS mounted home folder and on the local /tmp on silius with no difference.
</p>
<p>
Other things I'm trying:
</p>
<ul><li>running the ECL test-suite and comparing to another architectures (sage.math and skynet/eno)
</li></ul>
TicketfbisseyWed, 24 Aug 2011 23:44:45 GMT
https://trac.sagemath.org/ticket/11708#comment:18
https://trac.sagemath.org/ticket/11708#comment:18
<p>
I am not convinced that the problem is with ecl at all. I would try installing another lisp (unfortunately as far as I can see there are no lisps at all in the SuSE linux 11.SP1 DVDs) and compile maxima against that. If it still fail that would point towards maxima rather than ecl. If it builds that would point to ecl. clisp or sbcl would be appropriate. Unfortunately I don't have access to sagemath or boxen so I cannot login into silius right now.
</p>
TicketbenjaminfjonesThu, 25 Aug 2011 02:11:36 GMT
https://trac.sagemath.org/ticket/11708#comment:19
https://trac.sagemath.org/ticket/11708#comment:19
<p>
I've been trying to build clisp on skynet/silius without success. I've tried with both GCC version 4.6.1 and GCC version 4.3. Both build processes end with:
</p>
<pre class="wiki">./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)'
make: *** [interpreted.mem] Segmentation fault
</pre><p>
I'm going to move on and try compiling SBCL..
</p>
TicketbenjaminfjonesThu, 25 Aug 2011 02:48:16 GMT
https://trac.sagemath.org/ticket/11708#comment:20
https://trac.sagemath.org/ticket/11708#comment:20
<p>
My SBCL build (using ecl-11.1.1 as the cross compilation host) also failed:
</p>
<pre class="wiki">;;; Emitting code for LIST-OF-LENGTH-AT-LEAST-P.
Internal or unrecoverable error in:
not a lisp data object
[2: No such file or directory]
;;; ECL C Backtrace
</pre><p>
Same vague error as I get trying to build maxima.
</p>
<p>
I've <a class="ext-link" href="http://software.opensuse.org/114/en"><span class="icon"></span>searched</a> through the pre-built package lists for SUSE SLE 11 SP 1 looking for "clisp", "sbcl", "gcl", and "lisp" and didn't find anything.
</p>
TicketfbisseyThu, 25 Aug 2011 03:49:10 GMT
https://trac.sagemath.org/ticket/11708#comment:21
https://trac.sagemath.org/ticket/11708#comment:21
<p>
I couldn't find any lisp on the SLES DVDs either, I tried to look at <a class="missing wiki">RedHat?</a> because they also provide ppc64 but couldn't find anything so far. A source rpm of maxima or a lisp on ppc64 would have been helpful from any distros.
</p>
TicketbenjaminfjonesThu, 25 Aug 2011 04:36:31 GMTcc set
https://trac.sagemath.org/ticket/11708#comment:22
https://trac.sagemath.org/ticket/11708#comment:22
<ul>
<li><strong>cc</strong>
<em>mhansen</em> added
</li>
</ul>
<p>
I found Clozure CL project distributes binary images for ppc64 linux. I tried this out, but ran into yet more problems. Maybe this is going off on a tangent....
</p>
<pre class="wiki">bjones@silius:/tmp/bjones/ccl-1.7> ./ppccl64
remap spjump: Invalid argument
</pre><p>
Now I read through the platform notes <a class="ext-link" href="http://trac.clozure.com/ccl/wiki/PlatformNotes"><span class="icon"></span>here</a> and see that there is an issue with 16-bit memory references for functions like <code>NIL</code> (that sounds familiar...) not being accessible by non-root processes. This has to do with a parameter set by the OS: <code>mmap_min_addr</code>.
</p>
<pre class="wiki">The parameter in question is called mmap_min_addr; one can cat the file /proc/sys/vm/mmap_min_addr to see what the current setting is.
</pre><p>
On skynet/silius,
</p>
<pre class="wiki">bjones@silius:/tmp/bjones/ccl-1.7> cat /proc/sys/vm/mmap_min_addr
65536
</pre><p>
and according to the platform notes, it *should* be 4096.
</p>
<p>
In light of this, it might be worth changing this parameter on silius (which requires a reboot, see the platform notes above) and then try Clozure CL (run test suites, etc) and THEN try building Maxima. Also, it would be worth trying to reproduce Mike Hansen's reported error about redefining <code>NIL</code> <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/11705#comment:10"><span class="icon"></span>here</a> after the <code>mmap_min_addr</code> parameter has been changed.
</p>
TicketwasThu, 25 Aug 2011 05:13:58 GMT
https://trac.sagemath.org/ticket/11708#comment:23
https://trac.sagemath.org/ticket/11708#comment:23
<p>
Quick comment: Even if you could build Maxima with another Lisp, that's not a solution, since Sage uses the C library interface to Maxima, which is *only* available with ECL.
</p>
TicketfbisseyThu, 25 Aug 2011 05:19:52 GMT
https://trac.sagemath.org/ticket/11708#comment:24
https://trac.sagemath.org/ticket/11708#comment:24
<p>
@benjaminfjones
I think you are bang on. That is probably what is happening and what Mike Hansen was referring to. We should try the recommendation from the CCL web page and rebuild ecl and then maxima. From their comments doing the work in lisp to avoid the issue is not very appealing.
</p>
<p>
@was
My suggestion of doing so was to do "an isolation fault" procedure. It happened to have bear fruits in an unexcepted way.
</p>
TicketleifSat, 27 Aug 2011 04:28:08 GMT
https://trac.sagemath.org/ticket/11708#comment:25
https://trac.sagemath.org/ticket/11708#comment:25
<p>
So what's the current status?
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:12" title="Comment 12">was</a>:
</p>
<blockquote class="citation">
<p>
Do you want an account on the machine? Then you can try all this and maybe fix the problem!
</p>
<p>
Write me offlist at wstein@… for an account.
</p>
</blockquote>
<p>
William, did you receive my mail from last Friday (<em>"Re: Maxima/ECL on Silius (<a class="closed ticket" href="https://trac.sagemath.org/ticket/11708" title="defect: maxima doesn't build on Linux ppc64 (silius on skynet) (closed: worksforme)">#11708</a>)"</em>)?
</p>
<p>
I could try debugging / fixing this during the weekend.
</p>
TicketbenjaminfjonesMon, 29 Aug 2011 05:26:10 GMT
https://trac.sagemath.org/ticket/11708#comment:26
https://trac.sagemath.org/ticket/11708#comment:26
<p>
Current status is the same as it was in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/11708#comment:22"><span class="icon"></span>comment 22</a>. I'd to try building ECL + Maxima with the low memory access threshold changed. This requires root on the machine in question (but it's a simple change and easy to make permanent on reboot). I haven't asked Mariah about the possibility of doing this yet.
</p>
TicketleifMon, 29 Aug 2011 06:27:48 GMT
https://trac.sagemath.org/ticket/11708#comment:27
https://trac.sagemath.org/ticket/11708#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:26" title="Comment 26">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
I'd to try building ECL + Maxima with the low memory access threshold changed. This requires root on the machine in question (but it's a simple change and easy to make permanent on reboot). I haven't asked Mariah about the possibility of doing this yet.
</p>
</blockquote>
<p>
Well, this would probably prevent us from testing other, perhaps better solutions... ;-)
</p>
<p>
Similar machines will likely have the same problem, and I'm not sure whether everybody would lower the mmap min address since this is considered a security hole, at least in theory. And not every Sage user having access to such a machine will be able to do that, or to persuade a sysadmin to do so.
</p>
<p>
If <code>mmap()</code> is really the problem, one should be able to perhaps tweak / patch <code>configure</code>, or convince ECL in a different way to not (try to) use such low addresses. Furthermore, if that's really the cause, it is certainly a bug <em>how</em> (or when) ECL fails.
</p>
TicketbenjaminfjonesMon, 29 Aug 2011 14:04:13 GMT
https://trac.sagemath.org/ticket/11708#comment:28
https://trac.sagemath.org/ticket/11708#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:27" title="Comment 27">leif</a>:
</p>
<blockquote class="citation">
<p>
If <code>mmap()</code> is really the problem, one should be able to perhaps tweak / patch <code>configure</code>, or convince ECL in a different way to not (try to) use such low addresses. Furthermore, if that's really the cause, it is certainly a bug <em>how</em> (or when) ECL fails.
</p>
</blockquote>
<p>
I agree, but I think we should at least determine whether or not this is the current problem. I'm not advocating that Sage users on ppc64 machines fundamentally alter their OS in order to get Sage to compile.
</p>
TicketfbisseyWed, 31 Aug 2011 22:24:34 GMT
https://trac.sagemath.org/ticket/11708#comment:29
https://trac.sagemath.org/ticket/11708#comment:29
<p>
I think we should test if it is the problem too. I am currently installing some power 7 gear at my home university (university of Canterbury in New Zealand) so we will have alternative testing platform soon if that's a concern.
</p>
TicketleifThu, 01 Sep 2011 00:52:10 GMT
https://trac.sagemath.org/ticket/11708#comment:30
https://trac.sagemath.org/ticket/11708#comment:30
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:29" title="Comment 29">fbissey</a>:
</p>
<blockquote class="citation">
<p>
I think we should test if it is the problem too. I am currently installing some power 7 gear at my home university (university of Canterbury in New Zealand) so we will have alternative testing platform soon if that's a concern.
</p>
</blockquote>
<p>
I don't think ECL uses fixed mappings (in that range) at all.
</p>
<p>
Even if it did, <code>mmap()</code> should return <code>MAP_FAILED</code>, which is, as far as I can see, always catched, and the <em>returned</em> address used rather than the one passed. (You can of course test whether the kernel is buggy... :) )
</p>
TicketfbisseyTue, 13 Sep 2011 03:07:07 GMT
https://trac.sagemath.org/ticket/11708#comment:31
https://trac.sagemath.org/ticket/11708#comment:31
<p>
I tried a newer version of maxima just in case <a class="ext-link" href="http://spkg-upload.googlecode.com/files/maxima-5.25.1.spkg"><span class="icon"></span>http://spkg-upload.googlecode.com/files/maxima-5.25.1.spkg</a> but the result is the same not surprisingly.
</p>
<p>
Leif how did you get such a verbose output out of ecl in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11786" title="defect: Maxima fails to build if $HOME is not accessible (closed: invalid)">#11786</a> ?
</p>
TicketfbisseyTue, 13 Sep 2011 03:51:54 GMT
https://trac.sagemath.org/ticket/11708#comment:32
https://trac.sagemath.org/ticket/11708#comment:32
<p>
Found a way of stracing ecl, not that it is helpful
</p>
<pre class="wiki">write(1, ";;; Emitting code for UNARY", 27;;; Emitting code for UNARY) = 27
write(1, ".\n", 2.
) = 2
write(3, "}}\n", 3) = 3
write(3, "/*\tlocal function UNARY "..., 68) = 68
write(4, "#define STCK10\n", 15) = 15
write(3, "/*\toptimize speed 3, debug 2, sp"..., 68) = 68
write(3, "static cl_object LC21unary(volat"..., 67) = 67
write(3, "{ VT11 VLEX11 CLSR11 STCK11\n", 28) = 28
write(3, "\tconst cl_env_ptr cl_env_copy = "..., 51) = 51
write(3, "\tcl_object value0;\n", 19) = 19
write(3, "\tecl_cs_check(cl_env_copy,value0"..., 35) = 35
write(3, "\t{\n", 3) = 3
write(3, "TTL:\n", 5) = 5
write(3, "\t{cl_object V2; "..., 66) = 66
write(3, "\tV2= Cnil;\n", 11) = 11
write(3, "\tif(!((V1)==(VV[28]))){\n", 24) = 24
write(3, "\tgoto L3;}\n", 11) = 11
write(3, "\tT0= LC9next(lex0) "..., 67) = 67
write(3, "\tcl_env_copy->values[0]=LC10cond"..., 69) = 69
write(3, "\t{int V3=cl_env_copy->nvalues-0;"..., 33) = 33
write(3, "\tif (V3--<=0) goto L8;\n", 23) = 23
write(3, "\tV2= cl_env_copy->values[0];\n", 29) = 29
write(3, "\tif (V3--<=0) goto L9;\n", 23) = 23
write(3, "\tV1= cl_env_copy->values[1];\n", 29) = 29
write(3, "\tgoto L10;}\n", 12) = 12
write(3, "L8:;\n", 5) = 5
write(3, "\tV2= Cnil;\n", 11) = 11
write(3, "L9:;\n", 5) = 5
write(3, "\tV1= Cnil;\n", 11) = 11
write(3, "L10:;\n", 6) = 6
write(3, "\tif((V1)==(VV[29])){\n", 21) = 21
write(3, "\tgoto L13;}\n", 12) = 12
write(3, "\t(void)cl_error(1,_ecl_static_17"..., 67) = 67
write(3, "\tgoto L11;\n", 11) = 11
write(3, "L13:;\n", 6) = 6
write(3, "\tgoto L11;\n", 11) = 11
write(3, "L11:;\n", 6) = 6
write(3, "\tT0= LC9next(lex0) "..., 67) = 67
write(3, "\tcl_env_copy->nvalues=2;\n", 25) = 25
write(3, "\tcl_env_copy->values[1]=T0;\n", 28) = 28
write(3, "\tcl_env_copy->values[0]=V2;\n", 28) = 28
write(3, "\treturn cl_env_copy->values[0];\n", 32) = 32
write(3, "L3:;\n", 5) = 5
write(3, "\tif(!(ecl_numberp(V1))){\n", 25) = 25
write(3, "\tgoto L17;}\n", 12) = 12
write(3, "\tT0= LC9next(lex0) "..., 67) = 67
write(3, "\tcl_env_copy->nvalues=2;\n", 25) = 25
write(3, "\tcl_env_copy->values[1]=T0;\n", 28) = 28
write(3, "\tcl_env_copy->values[0]=V1;\n", 28) = 28
write(3, "\treturn cl_env_copy->values[0];\n", 32) = 32
write(3, "L17:;\n", 6) = 6
write(3, "\tif(!((V1)==(VV[26]))){\n", 24) = 24
write(3, "\tgoto L21;}\n", 12) = 12
write(3, "\tT0= LC9next(lex0) "..., 67) = 67
write(3, "\tcl_env_copy->nvalues=2;\n", 25) = 25
write(3, "\tcl_env_copy->values[1]=T0;\n", 28) = 28
write(3, "\tcl_env_copy->values[0]=V1;\n", 28) = 28
write(3, "\treturn cl_env_copy->values[0];\n", 32) = 32
write(3, "L21:;\n", 6) = 6
write(3, "\tif(!((V1)==(VV[30]))){\n", 24) = 24
write(3, "\tgoto L25;}\n", 12) = 12
write(3, "\tV1= LC9next(lex0) "..., 67) = 67
write(2, "\nInternal or unrecoverable error"..., 60
Internal or unrecoverable error in:
not a lisp data object
) = 60
write(2, " [2: No such file or directory]"..., 33 [2: No such file or directory]
) = 33
write(2, "\n;;; ECL C Backtrace\n", 21
;;; ECL C Backtrace
) = 21
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 106;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(si_dump_c_backtrace-0xb4cb4) [0x400001d28d4]
) = 106
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 105;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(ecl_internal_error-0xc2854) [0x400001c38c4]
) = 105
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 88;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(+0x17a3bc) [0x400001da3bc]
) = 88
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 97;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_type_of-0xadda4) [0x400001dab94]
) = 97
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 96;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_typep-0x192498) [0x400000e7d10]
) = 96
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 96;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_typep-0x192550) [0x400000e7c58]
) = 96
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x37950) [0x40000797950]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x37d60) [0x40000797d60]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x4e57c) [0x400007ae57c]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 88;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(+0x16caa0) [0x400001ccaa0]
) = 88
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x52024) [0x400007b2024]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 92;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(APPLY-0x87d68) [0x40000204200]
) = 92
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 113;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame-0xdfee8) [0x400001a2a68]
) = 113
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 95;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_apply-0xdfb50) [0x400001a2e48]
) = 95
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x4cd00) [0x400007acd00]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 88;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(+0x16cb0c) [0x400001ccb0c]
) = 88
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x55aa0) [0x400007b5aa0]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 98;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(APPLY_fixed-0x83d38) [0x40000208248]
) = 98
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 113;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame-0xdfeb8) [0x400001a2a98]
) = 113
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 95;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_apply-0xdfb50) [0x400001a2e48]
) = 95
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x4cd00) [0x400007acd00]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 88;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(+0x16cb0c) [0x400001ccb0c]
) = 88
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x55b30) [0x400007b5b30]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 98;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(APPLY_fixed-0x83d38) [0x40000208248]
) = 98
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 113;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame-0xdfeb8) [0x400001a2a98]
) = 113
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 95;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_apply-0xdfb50) [0x400001a2e48]
) = 95
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x4cd00) [0x400007acd00]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 88;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(+0x16cb0c) [0x400001ccb0c]
) = 88
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 91;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl-11.1.1/cmp.fas(+0x55b30) [0x400007b5b30]
) = 91
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 98;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(APPLY_fixed-0x83d38) [0x40000208248]
) = 98
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 113;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame-0xdfeb8) [0x400001a2a98]
) = 113
write(2, ";;; /home/fbissey/sage-4.7.2.alp"..., 95;;; /home/fbissey/sage-4.7.2.alpha2/local/lib/libecl.so.11.1(cl_apply-0xdfb50) [0x400001a2e48]
) = 95
</pre>
TicketfbisseyTue, 13 Sep 2011 05:07:09 GMT
https://trac.sagemath.org/ticket/11708#comment:33
https://trac.sagemath.org/ticket/11708#comment:33
<p>
OK I hacked something in ecl and now maxima is compiling... Cross finger that it will be successfull.
</p>
<pre class="wiki">src/c/main.d: 16*1024, /* ECL_OPT_C_STACK_SAFETY_AREA */
</pre><p>
I changed 16 to 64, ecl compiled and....
</p>
<pre class="wiki">;;; gcc -o lisp-cache/home/fbissey/sage-4.7.2.alpha2/spkg/build/maxima-5.25.1/src/src/maxima.fasb -L/home/fbissey/sage-4.7.2.alpha2/local/lib/ /tmp/eclinit8QaoTI.o lisp-cache/home/fbissey/sage-4.7.2.alpha2/spkg/build/maxima-5.25.1/src/src/libmaxima.a -Wl,--rpath,/home/fbissey/sage-4.7.2.alpha2/local/lib/ -shared -L/home/fbissey/sage-4.7.2.alpha2/local/lib -L/home/fbissey/sage-4.7.2.alpha2/local/lib -lecl -lgmp -lgc -ldl -lm
installing Maxima library as /home/fbissey/sage-4.7.2.alpha2/local/lib/ecl//maxima.fas
real 6m36.665s
user 5m44.422s
sys 0m30.499s
Successfully installed maxima-5.25.1
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
Making script relocatable
Finished installing maxima-5.25.1.spkg
fbissey@silius:~/sage-4.7.2.alpha2>
</pre><p>
:)
I'll have to downgrade maxima and run the test later but you can take over while real life is calling me.
</p>
TicketkcrismanTue, 13 Sep 2011 12:21:40 GMTupstream changed
https://trac.sagemath.org/ticket/11708#comment:34
https://trac.sagemath.org/ticket/11708#comment:34
<ul>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Not yet reported upstream; Will do shortly.</em>
</li>
</ul>
<p>
Nice. No idea how you guys figure this stuff out :)
</p>
<p>
Just be sure to report this potential fix upstream. Juanjo should be able to incorporate something reasonable.
</p>
TicketfbisseyTue, 13 Sep 2011 13:39:23 GMT
https://trac.sagemath.org/ticket/11708#comment:35
https://trac.sagemath.org/ticket/11708#comment:35
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:34" title="Comment 34">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Nice. No idea how you guys figure this stuff out :)
</p>
</blockquote>
<p>
To be honest, I have no idea myself sometimes :) I would need to be filmed in action. It all started with reading the bits about porting ecl to a new platform. Then inspect some of the files that page mentioned, the variable name jumped at me... I looked for it remembering previous comments on this threads. You could guess where 64 came from.
</p>
TicketjhpalmieriTue, 13 Sep 2011 15:59:53 GMT
https://trac.sagemath.org/ticket/11708#comment:36
https://trac.sagemath.org/ticket/11708#comment:36
<p>
I'm not having any luck with this. I took Sage 4.7.2.alpha2, put in the new tachyon spkg from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11706" title="defect: tachyon-0.98.9.p3 fails to build on ppc64 SUSE Linux power 7 (silius ... (closed: fixed)">#11706</a>, and modified ecl as described above (just one change in main.d). Neither the included version of maxima nor 5.25 (referenced <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:31" title="Comment 31">above</a>) compiles. Did I miss something, or do I just not have the magic touch?
</p>
TicketfbisseyTue, 13 Sep 2011 20:13:32 GMT
https://trac.sagemath.org/ticket/11708#comment:37
https://trac.sagemath.org/ticket/11708#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:36" title="Comment 36">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I'm not having any luck with this. I took Sage 4.7.2.alpha2, put in the new tachyon spkg from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11706" title="defect: tachyon-0.98.9.p3 fails to build on ppc64 SUSE Linux power 7 (silius ... (closed: fixed)">#11706</a>, and modified ecl as described above (just one change in main.d). Neither the included version of maxima nor 5.25 (referenced <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:31" title="Comment 31">above</a>) compiles. Did I miss something, or do I just not have the magic touch?
</p>
</blockquote>
<p>
Do you get the same error on UNARY or do you get something new?
</p>
TicketjhpalmieriTue, 13 Sep 2011 20:46:41 GMT
https://trac.sagemath.org/ticket/11708#comment:38
https://trac.sagemath.org/ticket/11708#comment:38
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:37" title="Comment 37">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:36" title="Comment 36">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I'm not having any luck with this. I took Sage 4.7.2.alpha2, put in the new tachyon spkg from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11706" title="defect: tachyon-0.98.9.p3 fails to build on ppc64 SUSE Linux power 7 (silius ... (closed: fixed)">#11706</a>, and modified ecl as described above (just one change in main.d). Neither the included version of maxima nor 5.25 (referenced <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:31" title="Comment 31">above</a>) compiles. Did I miss something, or do I just not have the magic touch?
</p>
</blockquote>
<p>
Do you get the same error on UNARY or do you get something new?
</p>
</blockquote>
<p>
It looks like the same error to me: it looks just like the message in the ticket description.
</p>
TicketbenjaminfjonesTue, 13 Sep 2011 20:50:54 GMT
https://trac.sagemath.org/ticket/11708#comment:39
https://trac.sagemath.org/ticket/11708#comment:39
<p>
I also tried your fix and ran into the same old error at the UNARY part of Maxima's build. Here's exactly what I did.
</p>
<ol start="0"><li>starting with sage-4.7.2.alpha2 on skynet/silius
</li><li>unpacked ecl-11.1.1.p1.spkg in a tmp directory
</li><li>modified the line in src/c/main.d, changing the 16 to a 64
</li><li>repacked the modified ecl-11.1.1.p1.spkg and put it in SAGE_ROOT/spkg/standard
</li><li>then ran make from SAGE_ROOT
</li></ol><p>
The ECL build finishes without error, but the Maxima build fails at the same point as before.
</p>
<p>
So you were saying that you were building a new spkg of maxima (or maybe of ECL). That could be the difference that John and I are seeing.
</p>
TicketfbisseyTue, 13 Sep 2011 21:49:48 GMT
https://trac.sagemath.org/ticket/11708#comment:40
https://trac.sagemath.org/ticket/11708#comment:40
<p>
That's weird I definitely have maxima installed on silius now
</p>
<pre class="wiki">fbissey@silius:~/sage-4.7.2.alpha2> export LD_LIBRARY_PATH=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse/lib64
fbissey@silius:~/sage-4.7.2.alpha2> ./sage
----------------------------------------------------------------------
| Sage Version 4.7.2.alpha2, Release Date: 2011-08-24 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: quit
Exiting Sage (CPU time 0m0.07s, Wall time 0m16.60s).
fbissey@silius:~/sage-4.7.2.alpha2> ./sage -t -long -force_lib devel/sage-main/sage/interfaces/maxima.py
init.sage does not exist ... creating
sage -t -long -force_lib "devel/sage-main/sage/interfaces/maxima.py"
**********************************************************************
File "/home/fbissey/sage-4.7.2.alpha2/devel/sage-main/sage/interfaces/maxima.py", line 124:
sage: a.expand()
Expected:
3*2^(7/2)+5*sqrt(2)+41
Got:
29*sqrt(2)+41
**********************************************************************
1 items had failures:
1 of 97 in __main__.example_0
***Test Failed*** 1 failures.
For whitespace errors, see the file /home/fbissey/.sage//tmp/.doctest_maxima.py
[30.9 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib "devel/sage-main/sage/interfaces/maxima.py"
Total time for all tests: 31.0 seconds
</pre><p>
That's an expected failure with maxima-5.25.{0,1}.
</p>
<p>
I'll try to rebuild from scratch and make a ecl spkg that is not a hack.
</p>
TicketfbisseyTue, 13 Sep 2011 21:52:05 GMT
https://trac.sagemath.org/ticket/11708#comment:41
https://trac.sagemath.org/ticket/11708#comment:41
<p>
I have made my home folder accessible on skynet so anyone can have a look at my install.
</p>
TicketfbisseyTue, 13 Sep 2011 23:53:07 GMT
https://trac.sagemath.org/ticket/11708#comment:42
https://trac.sagemath.org/ticket/11708#comment:42
<p>
The plot thicken. I am not sure yet that *my fix* actually does anything. We have a gcc problem... I couldn't reproduce the build for quite a while and even destroyed my working install. maxima will install if ecl has been compiled with gcc-4.3.4 that comes with SLES but not with gcc-4.6.1. I have managed to compile it the first time because I forgot to put gcc-4.6.1 back into my path after my ssh connection was broken one time too many.
</p>
<p>
Compiling ecl-11.1.1.p1 with gcc-4.3.4 to check if the fix does anything at all now...
</p>
TicketfbisseyWed, 14 Sep 2011 00:00:02 GMT
https://trac.sagemath.org/ticket/11708#comment:43
https://trac.sagemath.org/ticket/11708#comment:43
<p>
Confirmed. Fix does nothing gcc version used is what matters.
</p>
TicketkcrismanWed, 14 Sep 2011 01:20:05 GMT
https://trac.sagemath.org/ticket/11708#comment:44
https://trac.sagemath.org/ticket/11708#comment:44
<p>
Is it ok, though, if Linux PPC 64-bit is a relatively unusual platform and we could tell people to use a certain gcc? On Cygwin this would certainly be ok, since it's likely to only be used as a binary; here, maybe not.
</p>
TicketfbisseyWed, 14 Sep 2011 01:54:41 GMT
https://trac.sagemath.org/ticket/11708#comment:45
https://trac.sagemath.org/ticket/11708#comment:45
<p>
Well, the SLES install we have does not include gfortran so at the moment we have to get it from gcc-4.6.1. I have had some experience building gcc on power (power5 so far power7 any days now, ok so I had a G4 too)and it is a bit dodgy at times. I am not sure if it is dodgier on linux or AIX. On AIX I haven't had a g++ free of problems for example. I suspect that the gcc on silius could use a bit of massaging, the question is where and how. And finally it could very well be an obscure gcc bug that only shows up on power.
</p>
TicketfbisseyWed, 14 Sep 2011 02:10:26 GMT
https://trac.sagemath.org/ticket/11708#comment:46
https://trac.sagemath.org/ticket/11708#comment:46
<p>
Note that that SLES gcc has been built for power4 to ensure compatibility with a wide range of hardware
</p>
<pre class="wiki">gcc -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
</pre><p>
Not sure about the localy compiled gcc
</p>
<pre class="wiki">/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.6.1/src/gcc-4.6.1/configure --enable-languages=c,c++,fortran --with-gnu-as --with-gnu-as=/usr/local/binutils-2.21/ppc64-Linux-power7-suse-gcc-4.3.4-suse/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.21/ppc64-Linux-power7-suse-gcc-4.3.4-suse/bin/ld --with-gmp=/usr/local/mpir-2.4.0/ppc64-Linux-power7-suse-gcc-4.3.4-suse --with-mpfr=/usr/local/mpfr-3.0.1/ppc64-Linux-power7-suse-mpir-2.4.0-gcc-4.3.4-suse --with-mpc=/usr/local/mpc-0.9/ppc64-Linux-power7-suse-mpir-2.4.0-mpfr-3.0.1-gcc-4.3.4-suse --prefix=/usr/local/gcc-4.6.1/ppc64-Linux-power7-suse
Thread model: posix
gcc version 4.6.1 (GCC)
</pre><p>
There are a number of elements that could play right there from the config.
</p>
TicketleifWed, 14 Sep 2011 14:33:05 GMT
https://trac.sagemath.org/ticket/11708#comment:47
https://trac.sagemath.org/ticket/11708#comment:47
<p>
Funny that you <em>incidentally</em> compiled ECL with some other GCC version...
</p>
<p>
Perhaps also try some version from the 4.5 series.
</p>
<p>
Karl-Dieter, which upstream do you have in mind (now)? ;-)
</p>
<p>
<br />
</p>
<p>
Btw., the "native" SLES GCC is configured with <code>--enable-languages=...,fortran,...</code>, so in principle <code>gfortran</code> should be available, perhaps packaged separately though. (It's only a wrapper anyway, so should be replaceable by some simple shell script.)
</p>
TicketbenjaminfjonesWed, 14 Sep 2011 15:02:37 GMT
https://trac.sagemath.org/ticket/11708#comment:48
https://trac.sagemath.org/ticket/11708#comment:48
<p>
I added <code>CC=gcc-4.3; export CC</code> to the ECL's spkg-install script and after that change the maxima-5.23.2.p0 does indeed build successfully! I'm doing some tests now, will report back.
</p>
TicketkcrismanWed, 14 Sep 2011 15:22:44 GMT
https://trac.sagemath.org/ticket/11708#comment:49
https://trac.sagemath.org/ticket/11708#comment:49
<blockquote class="citation">
<p>
Karl-Dieter, which upstream do you have in mind (now)? ;-)
</p>
</blockquote>
<p>
I was wondering that myself, but didn't have anything germane to contribute.
</p>
TicketfbisseyWed, 14 Sep 2011 22:00:28 GMT
https://trac.sagemath.org/ticket/11708#comment:50
https://trac.sagemath.org/ticket/11708#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:47" title="Comment 47">leif</a>:
</p>
<blockquote class="citation">
<p>
Funny that you <em>incidentally</em> compiled ECL with some other GCC version...
</p>
</blockquote>
<p>
YEs, gave me a false sense of victory for a while. Lucky I figured out what
the recipe for success was. Imagine: we have a working install and no one knows
why or is able to reproduce it!
</p>
<blockquote class="citation">
<p>
Perhaps also try some version from the 4.5 series.
</p>
</blockquote>
<p>
Definitely something to try.
</p>
<blockquote class="citation">
<p>
Btw., the "native" SLES GCC is configured with <code>--enable-languages=...,fortran,...</code>, so in principle <code>gfortran</code> should be available, perhaps packaged separately though. (It's only a wrapper anyway, so should be replaceable by some simple shell script.)
</p>
</blockquote>
<p>
You would think so. However I cannot find anything on the sles11 dvds (for either x86_64 or ppc64) that mention explicitly fortran. It could be part of some other gcc rpm I need to have a closer look.
</p>
TicketleifWed, 14 Sep 2011 22:33:23 GMT
https://trac.sagemath.org/ticket/11708#comment:51
https://trac.sagemath.org/ticket/11708#comment:51
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:50" title="Comment 50">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:47" title="Comment 47">leif</a>:
</p>
<blockquote class="citation">
<p>
Funny that you <em>incidentally</em> compiled ECL with some other GCC version...
</p>
</blockquote>
<p>
YEs, gave me a false sense of victory for a while. Lucky I figured out what
the recipe for success was. Imagine: we have a working install and no one knows
why or is able to reproduce it!
</p>
</blockquote>
<p>
I was just wondering nobody (else) tried, <em>intentionally</em>... B)
</p>
<p>
Unfortunately I now also have an account there, but will first spend my time on the Sage 4.7.2.alpha3 release.
</p>
<p>
<br />
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Btw., the "native" SLES GCC is configured with <code>--enable-languages=...,fortran,...</code>, so in principle <code>gfortran</code> should be available, perhaps packaged separately though. (It's only a wrapper anyway, so should be replaceable by some simple shell script.)
</p>
</blockquote>
<p>
You would think so. However I cannot find anything on the sles11 dvds (for either x86_64 or ppc64) that mention explicitly fortran. It could be part of some other gcc rpm I need to have a closer look.
</p>
</blockquote>
<p>
There are at least PPC ones for openSUSE (GCC 4.3), e.g. <a class="ext-link" href="http://www.rpmseek.com/rpm-dl/gcc43-fortran-4.3.1_20080507-6.1.ppc.html?hl=en&cs=gcc43-fortran:PR:0:0:0:0:0:8231772"><span class="icon"></span>here</a>.
</p>
<p>
Other versions (>4.3.x) should IMHO also work, or grab the sources and build it yourself... ;-)
</p>
TicketfbisseyWed, 14 Sep 2011 22:42:26 GMT
https://trac.sagemath.org/ticket/11708#comment:52
https://trac.sagemath.org/ticket/11708#comment:52
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:51" title="Comment 51">leif</a>:
</p>
<blockquote class="citation">
<p>
There are at least PPC ones for openSUSE (GCC 4.3), e.g. <a class="ext-link" href="http://www.rpmseek.com/rpm-dl/gcc43-fortran-4.3.1_20080507-6.1.ppc.html?hl=en&cs=gcc43-fortran:PR:0:0:0:0:0:8231772"><span class="icon"></span>here</a>.
</p>
</blockquote>
<p>
It is definitely not on the dvd for sles 11. I will try my own 4.6.1.
</p>
TicketleifWed, 14 Sep 2011 22:46:57 GMT
https://trac.sagemath.org/ticket/11708#comment:53
https://trac.sagemath.org/ticket/11708#comment:53
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:52" title="Comment 52">fbissey</a>:
</p>
<blockquote class="citation">
<p>
It is definitely not on the dvd for sles 11. I will try my own 4.6.1.
</p>
</blockquote>
<p>
I can only tell that 4.5.x's works with both GCC 4.3.x and 4.4.x.
</p>
TicketleifWed, 14 Sep 2011 23:03:01 GMT
https://trac.sagemath.org/ticket/11708#comment:54
https://trac.sagemath.org/ticket/11708#comment:54
<p>
Did you play with optimization flags when building the ECL spkg?
</p>
<p>
By default it uses <code>-O2</code>; if you set <code>SAGE_DEBUG=yes</code>, it will be built with <code>-O0</code>.
</p>
<p>
<code>spkg-install</code> looks quite ugly [again?] btw., the following for example is definitely wrong:
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">CPPFLAGS</span><span class="o">=</span><span class="s2">"$CPPFLAGS -I$SAGE_LOCAL/include"</span>
<span class="nv">LDFLAGS</span><span class="o">=</span><span class="s2">"$LDFLAGS -L$SAGE_LOCAL/lib"</span>
</pre></div></div><p>
(The order has to be changed in both cases.)
</p>
TicketfbisseyWed, 14 Sep 2011 23:10:00 GMT
https://trac.sagemath.org/ticket/11708#comment:55
https://trac.sagemath.org/ticket/11708#comment:55
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:54" title="Comment 54">leif</a>:
</p>
<blockquote class="citation">
<p>
Did you play with optimization flags when building the ECL spkg?
</p>
<p>
By default it uses <code>-O2</code>; if you set <code>SAGE_DEBUG=yes</code>, it will be built with <code>-O0</code>.
</p>
<p>
<code>spkg-install</code> looks quite ugly [again?] btw., the following for example is definitely wrong:
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">CPPFLAGS</span><span class="o">=</span><span class="s2">"$CPPFLAGS -I$SAGE_LOCAL/include"</span>
<span class="nv">LDFLAGS</span><span class="o">=</span><span class="s2">"$LDFLAGS -L$SAGE_LOCAL/lib"</span>
</pre></div></div><p>
(The order has to be changed in both cases.)
</p>
</blockquote>
<p>
Haven't but that's a good idea. I may have OK-ed those change quickly for .p1 when
a problem appeared with altivec and I caouldn't make a new spkg myself due to time
constraints.
</p>
TicketbenjaminfjonesFri, 16 Sep 2011 04:10:57 GMT
https://trac.sagemath.org/ticket/11708#comment:56
https://trac.sagemath.org/ticket/11708#comment:56
<p>
Playing around with the <code>SAGE_DEBUG=yes</code> flag, I've that ECL doesn't even build on skynet/silius using the default system GCC 4.6.1. The ECL build fails with:
</p>
<pre class="wiki">;;; Compiling (DEFUN PPRINT-RAW-ARRAY ...).
;;; Compiling (DEFUN PPRINT-LAMBDA-LIST ...).
;;;;;; Stack overflow.
;;; Jumping to the outermost toplevel prompt
;;;
</pre><p>
Without <code>SAGE_DEBUG</code> set, it builds fine (but them Maxima fails, of course).
</p>
TicketbenjaminfjonesFri, 16 Sep 2011 17:49:58 GMT
https://trac.sagemath.org/ticket/11708#comment:57
https://trac.sagemath.org/ticket/11708#comment:57
<p>
Even though Maxima builds when we force ECL to compile under GCC-4.3 on silius, the resulting Sage installation has *lots* of doctest errors. See the <a class="ext-link" href="http://sage.math.washington.edu/home/bjones/ptestlong.log"><span class="icon"></span>ptestlong.log</a> file.
</p>
<p>
At a glance, there are a couple different errors happening:
</p>
<ol><li><a class="missing wiki">OverflowError?</a>: value too large to convert to int (may have to do with the architecture?)
</li><li>A couple of <code>NameError</code>s in <code>optimize.py</code> and <code>pushout.py</code>
</li></ol><pre class="wiki">File "/tmp/bjones/sage-4.7.2.alpha2/devel/sage-main/sage/numerical/optimize.py", line 571:
sage: fit[a], fit[b], fit[c]
Exception raised:
Traceback (most recent call last):
File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/tmp/bjones/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_7[8]>", line 1, in <module>
fit[a], fit[b], fit[c]###line 571:
sage: fit[a], fit[b], fit[c]
NameError: name 'fit' is not defined
</pre><ol start="3"><li>mpfr errors: <code>RuntimeError: Aborted</code>
</li><li>many <code> ValueError: Refining interval that does not bound unique root!</code> type errors from the elliptic curves modules
</li></ol><p>
etc..
</p>
TicketfbisseyFri, 16 Sep 2011 20:13:14 GMT
https://trac.sagemath.org/ticket/11708#comment:58
https://trac.sagemath.org/ticket/11708#comment:58
<p>
I think you should put this in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11705" title="enhancement: Port Sage to SUSE Linux Power 7 (ppc64). (closed: fixed)">#11705</a> as at first glance errors are not just from maxima. I am going into that log with a fine comb.
</p>
TicketjhpalmieriWed, 02 Nov 2011 20:27:03 GMT
https://trac.sagemath.org/ticket/11708#comment:59
https://trac.sagemath.org/ticket/11708#comment:59
<p>
Now I'm confused: I just successfully built Sage 4.7.2.alpha4 on silius, with gcc 4.6.2 (the default on that machine). I had to replace the mpir package with the one from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11964" title="defect: MPIR: Use proper ABI name on Linux PPC64 (closed: fixed)">#11964</a>, but that was the only change. Can anyone else verify this? I see that mpir is a dependency of ecl; could the new mpir spkg have fixed the problem with maxima? If so, we can close this ticket.
</p>
<p>
With the build, I do get lots of test failures, as above. I'll post the log at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11705" title="enhancement: Port Sage to SUSE Linux Power 7 (ppc64). (closed: fixed)">#11705</a>.
</p>
TicketfbisseyWed, 02 Nov 2011 20:53:10 GMT
https://trac.sagemath.org/ticket/11708#comment:60
https://trac.sagemath.org/ticket/11708#comment:60
<p>
It could. I have to take some time to do a build but the log from Benjamin indicated there was a lot of trouble potentially with mpir. So it could indeed have been cured by the upgrade, although it is difficult to guess the chain of event leading to that. Unless there is a competition between mpir/gmp used by gcc and the one installed in sage.
</p>
TicketleifWed, 02 Nov 2011 20:58:29 GMT
https://trac.sagemath.org/ticket/11708#comment:61
https://trac.sagemath.org/ticket/11708#comment:61
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:59" title="Comment 59">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Now I'm confused: I just successfully built Sage 4.7.2.alpha4 on silius, with gcc 4.6.2 (the default on that machine). I had to replace the mpir package with the one from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11964" title="defect: MPIR: Use proper ABI name on Linux PPC64 (closed: fixed)">#11964</a>, but that was the only change. Can anyone else verify this?
</p>
</blockquote>
<p>
I haven't tried GCC 4.6.2 yet, although I downloaded it the day it had been released ;-) (but hadn't had the time to build it on Silius)
</p>
<p>
Perhaps they've fixed some things, although my impression was that something with ECL is wrong.
</p>
<p>
Note that I've previously built ECL and Maxima "successfully" (modulo lots of doctest errors) with <code>-mcpu=power4 -mtune=power4</code> (Maxima uses the <code>CFLAGS</code> from ECL anyway), and Sage with GCC 4.6.1 and GCC 4.4.6 (the other parts with <code>-mcpu=power7 -mtune=power7</code>).
</p>
<p>
<br />
</p>
<blockquote class="citation">
<p>
I see that mpir is a dependency of ecl; could the new mpir spkg have fixed the problem with maxima? If so, we can close this ticket.
</p>
</blockquote>
<p>
No, it just triggered the rebuild of ECL with GCC 4.6.2.
</p>
<p>
(I did build Sage 4.7.2.alpha3 which has [almost] the same MPIR spkg, i.e., the p4; the p7 just fixes a <code>configure</code> regression introduced by the p5/p6.)
</p>
<p>
I wouldn't close this ticket unless you know that none of the doctest errors is related to / caused by Maxima.
</p>
TicketjhpalmieriWed, 02 Nov 2011 21:08:18 GMT
https://trac.sagemath.org/ticket/11708#comment:62
https://trac.sagemath.org/ticket/11708#comment:62
<p>
Just to clarify: I logged into silius, sourced <code>/usr/local/skynet_bash_profile</code>, set <code>MAKE='make -j12'</code> and <code>SAGE_PARALLEL_SPKG_BUILD=yes</code>, and typed <code>make</code>. I didn't modify any other settings. gcc-4.6.2 is the default compiler there now.
</p>
TicketleifWed, 02 Nov 2011 21:14:48 GMT
https://trac.sagemath.org/ticket/11708#comment:63
https://trac.sagemath.org/ticket/11708#comment:63
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:62" title="Comment 62">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Just to clarify: I logged into silius, sourced <code>/usr/local/skynet_bash_profile</code>, set <code>MAKE='make -j12'</code> and <code>SAGE_PARALLEL_SPKG_BUILD=yes</code>, and typed <code>make</code>. I didn't modify any other settings. gcc-4.6.2 is the default compiler there now.
</p>
</blockquote>
<p>
Which means that upgrading from 4.6.1 to 4.6.2 seems worthwhile, although it's not immediately clear (or I don't know yet) what they changed. It is configured slightly differently, but without <code>--with-cpu=...</code> etc.; it might just default to some other CPU now.
</p>
<p>
Can anybody look at the GCC diffs? I didn't have and don't have the time right now...
</p>
TicketjdemeyerFri, 13 Jan 2012 14:43:27 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/11708#comment:64
https://trac.sagemath.org/ticket/11708#comment:64
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-4.8</em> to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
<p>
Proposing to close this, since building sage-4.8.alpha6 on silius works. There are many test failures (probably unrelated to ecl) but at least it builds.
</p>
TicketleifFri, 13 Jan 2012 20:52:10 GMT
https://trac.sagemath.org/ticket/11708#comment:65
https://trac.sagemath.org/ticket/11708#comment:65
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11708#comment:64" title="Comment 64">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Proposing to close this, since building sage-4.8.alpha6 on silius works. There are many test failures (probably unrelated to ecl) but at least it builds.
</p>
</blockquote>
<p>
Unless a couple of doctest failures are caused by ECL and/or Maxima...
</p>
<p>
Maybe François can tell better.
</p>
<p>
I don't know right now what Maxima/ECL/GCC version you are referring to, but at least [with] GCC 4.6.x [ECL] seemed to produce buggy or invalid code for POWER7; <code>-mcpu=power4</code> in contrast "worked", at least better, i.e. did build and produced less test failures. [Note that Maxima uses those <code>CFLAGS</code> specified when configuring ECL.]
</p>
TicketjdemeyerFri, 05 Oct 2012 19:25:56 GMTstatus changed; reviewer, resolution set
https://trac.sagemath.org/ticket/11708#comment:66
https://trac.sagemath.org/ticket/11708#comment:66
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>closed</em>
</li>
<li><strong>reviewer</strong>
set to <em>Jeroen Demeyer</em>
</li>
<li><strong>resolution</strong>
set to <em>worksforme</em>
</li>
</ul>
<p>
I'm closing this since maxima <em>does</em> build on silius. If there are doctest failures related to the building of Maxima, that's for a different ticket.
</p>
Ticket