https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-mathematics/fricas-1.3.11-r2 fails to compile. Discovered on: amd64 (internal ref: ci) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 896685 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
Error(s) that match a know pattern in addition to what has been reported in the summary: ; (BOOT::|error| "A required BPI does not exist.") ; (BOOT::|error| "Union bug: Cannot find appropriate branch for coerce to E") ; (BOOTTRAN::CONCAT "INCLUSION SYNTAX ERROR IN LINE " cmp: tmp/examples.list: No such file or directory ; (CONS " Cannot find part of" echo "PREGENERATED directory does not exist."; \ ; (FORMAT T "******** Spad syntax error detected ********") mv: cannot stat 'btincl2.data': No such file or directory mv: cannot stat 'btincl2.fn': No such file or directory mv: cannot stat 'btincl2.lib': No such file or directory mv: cannot stat 'btpile2.data': No such file or directory mv: cannot stat 'btpile2.fn': No such file or directory mv: cannot stat 'btpile2.lib': No such file or directory mv: cannot stat 'btscan2.data': No such file or directory mv: cannot stat 'btscan2.fn': No such file or directory mv: cannot stat 'btscan2.lib': No such file or directory mv: cannot stat 'ptyout.data': No such file or directory mv: cannot stat 'ptyout.fn': No such file or directory mv: cannot stat 'ptyout.lib': No such file or directory mv: cannot stat 'typars.data': No such file or directory mv: cannot stat 'typars.fn': No such file or directory mv: cannot stat 'typars.lib': No such file or directory mv: cannot stat 'typrops.data': No such file or directory mv: cannot stat 'typrops.fn': No such file or directory mv: cannot stat 'typrops.lib': No such file or directory mv: cannot stat 'tytree1.data': No such file or directory mv: cannot stat 'tytree1.fn': No such file or directory mv: cannot stat 'tytree1.lib': No such file or directory ; "\spad{coerce(u)} returns \spad{x} of type \spad{A} if \spad{x} is of branch \spad{a} of the union. Error: if \spad{u} is of branch \spad{b} of the union.") ; "\spad{coerce(u)} returns \spad{x} of type \spad{A} if \spad{x} is of the \spad{A} branch of the union. Error: if \spad{u} is of the \spad{B} branch of the union.") ; "\spad{coerce(u)} returns \spad{x} of type \spad{B} if \spad{x} is of branch \spad{b} branch of the union. Error: if \spad{u} is of the \spad{a} branch of the union.") ; "\spad{coerce(u)} returns \spad{x} of type \spad{B} if \spad{x} is of the \spad{B} branch of the union. Error: if \spad{u} is of the \spad{A} branch of the union.") ; "\spad{r . a := x} destructively replaces the value stored in record \spad{r} under selector \spad{a} by the value of \spad{x}. Error: if \spad{r} has not been previously assigned a value.") ; "\spad{r . b := y} destructively replaces the value stored in record \spad{r} under selector \spad{b} by the value of \spad{y}. Error: if \spad{r} has not been previously assigned a value.")))) ; (BOOT::|userError| "Parsing error: illegal toplevel form")
I emerged it successfully with sbcl. It seems you use clisp. clisp is by far too slow, sbcl is much faster and quite reliable. In principle, fricas should be compilable by clisp; many years ago I checked it for some old version of fricas (now not in the tree). Maybe, some change in fricas has led to incompatibility with clisp. Yes, in principle it would be good to check compatibility with *all* lisps which, as declared, should be able to compile fricas. But it is so much work... And sbcl is so much better that the others...
I think the problem is only with USE=doc
Interesting. I've reproduced this hang once: it seems that one figure for the book is being generated by fricas forever, with 100% processor use, I had to hit ctrl-c after waiting for 10 minutes. But after that I've emerged fricas with USE=doc successfully 2 times (I use sbcl). Seems to be something probabilistic.
ci has reproduced this issue with version 1.3.11-r3 - Updating summary.
First, from the log, I can see that fricas is built with SBCL, not CLISP. Second, the "mv" errors can be safely ignored. It is only useful when building with GCL. Third, I can not reproduce it locally. I suspect it might be related with 'MAKEOPTS=-j60' in the ci box. Anyway, can you upload the latest build log? It would be better if we can get output of "ps aux" to see which process is hanged.
There seems to be some race condition. For me, fricas[doc,sbcl] compiles fine in a bast majority of cases. However, once or twice I got this hung while producing the documentation. Completely at random.
(In reply to Andrey Grozin from comment #8) > There seems to be some race condition. For me, fricas[doc,sbcl] compiles > fine in a bast majority of cases. However, once or twice I got this hung > while producing the documentation. Completely at random. didn't read the entire thread, but does -j1 help somehow?