Greetings!
Robert Dodier <robert.dod...@gmail.com> writes:
> Condition in MACSYMA-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR:
> The assertion v && (unsigned long)(v+sz)<MAX_CODE_ADDRESS on line 1029
> of alloc.c in function alloc_code_space failed: Success
>
> However, that isn't entirely repeatable. I tried it again and it
> failed again, but then I tried it again and it worked okay.
After a bit of investigation, it does appear that gcc, at least as of
version 11, does implement "-mcmodel=large" now without obvious bugs.
The performance hit also appears minimal or non-existent.
I am considering moving to this as the default and eliminating this
runtime requirement on amd64 to ensure that the load address is <2gb.
Every other solution is ad-hoc: 1) saved some memory of some guessed
size early on below 2gb, 2) play with the memory bounds and hope gc will
free enough space below 2gb, 3) attempt to recompile the file (at load
time!) if the conflict is detected, etc.
Note for those interested, there is a current bug in gcc-12 which
segfaults the maxima testsuite (in gcd).
>
> Another kind of error is shown by:
>
> (%i1) load ("pslq");
>
> filename_merge: unexpected argument:
> "/home/dodier/maxima/maxima-code/share/pslq//pslq_integer_relation.lisp"
>
> Looks like the problem is that the construct path contains "//"
> instead of just "/".
This is true, gcl's parse-namestring cannot deal with the '//', which is
not an ansi namestring to my understanding. Can you remove before
concatenation?
Take care,
>
> best
>
> Robert
>
>
>
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
