On Mon, Feb 12, 2024 at 07:02:39AM -0800, 'Martin R' via FriCAS - computer
algebra system wrote:
> Dima reports the following on
> https://github.com/sagemath/sage/pull/37041#issuecomment-1938698041
>
> Apparently, this is using ecl (using the standard SageMath setup).
> Unfortunately, I cannot help except for reporting, because I do not have
> access to a mac.
>
> It would be wonderful if you could help! Best wishes,
>
> Martin
>
> ----message by Dima ----
>
> at the moment, with a recent bunch of macOS tools on M1, fricas in Sage
> just doesn't build:
> ;;; Style warning:
> ;;; in file define.clisp, position 165810
> ;;; at (DEFUN DomainSubstitutionFunction,Subst ...)
> ;;; ! Variable $extraParms was undefined. Compiler assumes it is a
> global.thread_suspend failed
^^^^^^^^^^^^^^^^^^^^^
This message is printed by function 'GC_stop_world' in
'src/bdwgc/darwin_stop_world.c' in ECL sources. That is clearly
internal thing to ECL and ECL folks (or maybe whoever is maintaining
Boehm-Demers-Weiser garbage collector) are right people to ask.
>
> ;;; Internal error:
> ;;; ** Error code 6 when executing
> ;;; (EXT:RUN-PROGRAM "clang" ("-I."
> "-I/opt/homebrew/Cellar/ecl/23.9.9/include/"
> "-I/opt/homebrew/opt/gmp/include"
> "-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/include"
> "-I/opt/homebrew/opt/bdw-gc/include" "-g" "-O2" "-fPIC" "-fno-common"
> "-D_THREAD_SAFE" "-Ddarwin" "-O2" "-c" "define.c" "-o" "define.o")):
Again, this looks like error message from ECL.
> ;;; make[5]: *** [define.o] Error 1
> make[4]: *** [all-interpsys] Error 2
> make[3]: *** [all-src] Error 2
> ********************************************************************************
> Error building fricas-1.3.10
This looks like ECL problem. Of course, it is possible that
something is not kosher in FriCAS code and this causes failure.
But ATM the only lead is to ECL internals. I affraid that the
best I could in principle do is to find smaller testcase than whole
FriCAS sources. But event that is not possible without a way
to reproduce the problem.
Anyway, smaller testcase should be possible using script for
build from Lisp files (posted by Qian) and .lisp/.clisp files
from build say on x86_64. If this is problem with garbage
collector (as it looks), then it is likely that to reproduce
it one must load exactly the same things into running Lisp image.
But basically, one has to try, either result would give extra
info. It is possible that merely recompiling 'define.clisp'
in appropriate environment is already enough to trigger the
problem. But without access to failing build environment
it is pure speculation...
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZcpmNKJb5IUy2Xrx%40fricas.org.
