Does this also happen if you build the Sage source tarball? It could just 
be a bug in the Gentoo overlay. I've never seen that happen with vanilla 
Sage.



On Saturday, April 25, 2015 at 4:49:27 PM UTC-4, Gregor Bruns wrote:
>
>  Whenever I try something with symbolic manipulation in Sage, ECL throws 
> an error:
>
> var('x')
> simplify(x^3)
> Internal or unrecoverable error in:
> Got signal before environment was installed on our thread
> [2: No such file or directory]
>
> ;;; ECL C Backtrace
> ;;; /usr/lib64/libecl.so.13.5(si_dump_c_backtrace+0x31) [0x7f30c79e45f1]
> ;;; /usr/lib64/libecl.so.13.5(ecl_internal_error+0x44) [0x7f30c79cd5c4]
> ;;; /usr/lib64/libecl.so.13.5(+0x1b8578) [0x7f30c79fa578]
> ;;; /lib64/libpthread.so.0(+0xfeb0) [0x7f3105cc5eb0]
> ;;; /usr/lib64/libgc.so.1(+0x8bcd) [0x7f30f2130bcd]
> ;;; /usr/lib64/libgc.so.1(+0x68eb) [0x7f30f212e8eb]
> ;;; /usr/lib64/libgc.so.1(+0x6c4e) [0x7f30f212ec4e]
> ;;; /usr/lib64/libgc.so.1(+0x13a94) [0x7f30f213ba94]
> ;;; /usr/lib64/libgc.so.1(+0x87d3) [0x7f30f21307d3]
> ;;; /usr/lib64/libgc.so.1(+0xd659) [0x7f30f2135659]
> ;;; /usr/lib64/libgc.so.1(GC_generic_malloc+0x47) [0x7f30f2135757]
> ;;; /usr/lib64/libgc.so.1(+0xdada) [0x7f30f2135ada]
> ;;; /usr/lib64/libecl.so.13.5(ecl_alloc_object+0x9b) [0x7f30c7a10f7b]
> ;;; /usr/lib64/libecl.so.13.5(init_threads+0x42) [0x7f30c7a0e172]
> ;;; /usr/lib64/libecl.so.13.5(cl_boot+0x87) [0x7f30c78dd377]
> ;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x6c6c) 
> [0x7f30c7d6dc6c]
> ;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x6f98) 
> [0x7f30c7d6df98]
> ;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(initecl+0x1781) 
> [0x7f30c7d79961]
> ;;; /usr/lib64/libpython2.7.so.1.0(_PyImport_LoadDynamicModule+0x99) 
> [0x7f3105fc4a39]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xefc29) [0x7f3105fc2c29]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xefe6d) [0x7f3105fc2e6d]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x188) 
> [0x7f3105fc37d8]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xd792f) [0x7f3105faa92f]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f3105f1d593]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) 
> [0x7f3105fac477]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0xf05) 
> [0x7f3105fad965]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7dd) 
> [0x7f3105fb251d]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32) [0x7f3105fb2622]
> ;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0x8c) 
> [0x7f3105fc1d9c]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xef005) [0x7f3105fc2005]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xefc29) [0x7f3105fc2c29]
> ;;; /usr/lib64/libpython2.7.so.1.0(+0xefe6d) [0x7f3105fc2e6d]
> Aborted
>
> I'm running Sage 6.6
>
> version()
> 'SageMath Version 6.6, Release Date: 2015-04-14'
>
> on Gentoo Linux using the sage-on-gentoo overlay.
>
> uname -a
>
> Linux t-rex 3.17.7-gentoo #1 SMP Mon Dec 22 12:30:30 CET 2014 x86_64 
> Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz GenuineIntel GNU/Linux
>
> I tried reinstalling every related package (sage, maxima, ecls) several 
> times, removing and reenabling threads support, even remerging my whole 
> system, without success. Recently I created a sandbox and installed 
> everything from scratch there - same error.
> Symbolic computation in Maxima itself is just fine, though.
>
> Does anyone have an idea what could cause this problem? Or what is even 
> meant by the error? What file or directory isn't found? Thanks in advance.
>  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

Reply via email to