This is just Sage's LD_LIBRARY_PATH hurting us once more, you are pretty
much in a world of pain if system libraries don't match the Sage version.
On Sunday, October 20, 2013 6:45:34 AM UTC+1, rickhg12hs wrote:
>
> Trying to run `runsnake` from within sage commandline fails on my Fedora
> 19 sy
Since Sage depends on the host system's runsnake command, how about letting
it have its LD_LIBRARY_PATH to run? Changing one line in
.../sage/misc/dev_tools.py allows it to work on my system.
Last line of current runsnake definition:
os.system("/usr/bin/python -E `which runsnake` %s &"%tmp
On Monday, October 21, 2013 10:39:03 PM UTC-7, rickhg12hs wrote:
>
> Since Sage depends on the host system's runsnake command, how about
> letting it have its LD_LIBRARY_PATH to run? Changing one line in
> .../sage/misc/dev_tools.py allows it to work on my system.
>
> Last line of current runs
Hmmm, maybe I was lucky. The trac fix works for me too.
Should sage have a few/several more "SAGE_ORIG_" vars for
sage-native-execute
to restore?
On Tuesday, October 22, 2013 2:05:52 AM UTC-4, Nils Bruin wrote:
>
>
>
> On Monday, October 21, 2013 10:39:03 PM UTC-7, rickhg12hs wrote:
>>
>>
On 10/22/13 12:39 AM, rickhg12hs wrote:
Since Sage depends on the host system's runsnake command, how about
letting it have its LD_LIBRARY_PATH to run? Changing one line in
.../sage/misc/dev_tools.py allows it to work on my system.
Last line of current runsnake definition:
os.system("/usr
On Tuesday, October 22, 2013 10:36:30 AM UTC+1, Jason Grout wrote:
>
> It certainly can be improved
>
The best way to improve on the sage-native-execute script would be to get
rid of it and the LD_LIBRARY_PATH hack, of course. Thats what rpath is for.
See also http://trac.sagemath.org/10572
--
On 10/22/13 4:42 AM, Volker Braun wrote:
The best way to improve on the sage-native-execute script would be to
get rid of it and the LD_LIBRARY_PATH hack, of course. Thats what rpath
is for. See also http://trac.sagemath.org/10572
Cool! How close is the ticket to being done?
Jason
--
You r
On 10/22/13 4:42 AM, Volker Braun wrote:
The best way to improve on the sage-native-execute script would be to
get rid of it and the LD_LIBRARY_PATH hack, of course. Thats what rpath
is for. See also http://trac.sagemath.org/10572
Wait: so how does this fix, say, invoking Octave? Octave isn't
On Tuesday, October 22, 2013 11:25:31 AM UTC+1, Jason Grout wrote:
>
> On 10/22/13 4:42 AM, Volker Braun wrote:
> > The best way to improve on the sage-native-execute script would be to
> > get rid of it and the LD_LIBRARY_PATH hack, of course. Thats what rpath
> > is for. See also http://trac.
On Tuesday, October 22, 2013 11:27:44 AM UTC+1, Jason Grout wrote:
>
> Wait: so how does this fix, say, invoking Octave? Octave isn't compiled
> by Sage at all---we just invoke the system Octave.
If you don't set LD_LIBRARY_PATH then calling the system octave (or any
other binary) just works
On 10/22/13 5:42 AM, Volker Braun wrote:
If you don't set LD_LIBRARY_PATH then calling the system octave (or any
other binary) just works as it would if you run it without Sage.
Oh, right. Of course.
Thanks,
Jason
--
You received this message because you are subscribed to the Google Groups
Using the fix in:
http://trac.sagemath.org/ticket/14414
... runsnake works fine on my system (Fedora 19, Sage 5.12). The trac fix
uses sage-native-execute.
On Tue, Oct 22, 2013 at 5:36 AM, Jason Grout wrote:
> On 10/22/13 12:39 AM, rickhg12hs wrote:
>
>> Since Sage depends on the host system'
12 matches
Mail list logo
