Should freetype be updated in Sage?

[rickhg12hs]

Trying to run `runsnake` from within sage commandline fails on my Fedora 19 system.  `runsnake` on my system requires that `libfreetype` define symbol `FT_Face_GetCharVariantIndex` which started in `freetype` version 2.3.6.  Currently Sage is distributed with `freetype` version 2.3.5.  Fedora 19 is distributed with `freetype` version 2.4.11.

Perhaps Sage could update its version of freetype and/or use the host system's freetype library?

[Volker Braun]

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.

[rickhg12hs]

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 &"%tmpfile)

Proposed change to use host system's LD_LIBRARY_PATH:

    os.system("LD_LIBRARY_PATH=${SAGE_ORIG_LD_LIBRARY_PATH} /usr/bin/python -E `which runsnake` %s &"%tmpfile)

This change seems pretty low risk since one can't expect Sage to fix a "broken" runsnake on the local host (i.e., if runsnake doesn't work on the host, it's not going to work with Sage, or anything else, either), and runsnake only reads the tmpfile generated by Sage without any other interaction with Sage (as far as I know).

I don't know why freetype is being held at the current version in Sage, but the above change should allow runsnake to work regardless.

[Nils Bruin]

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 runsnake definition:

    os.system("/usr/bin/python -E `which runsnake` %s &"%tmpfile)

See

http://trac.sagemath.org/ticket/14414
 
If you can get away with resetting only LD_LIBRARY_PATH, congratulations, but there are a few more variables that are problematic when you try to run native python programs in the environment that sage sets up.

[rickhg12hs]

Hmmm, maybe I was lucky.  The trac fix works for me too.

Should sage have a few/several more "SAGE_ORIG_XXXX" vars for sage-native-execute to restore?

[Jason Grout]

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/bin/python -E `which runsnake` %s &"%tmpfile)
>
> Proposed change to use host system's LD_LIBRARY_PATH:
>
> os.system("LD_LIBRARY_PATH=${SAGE_ORIG_LD_LIBRARY_PATH}
> /usr/bin/python -E `which runsnake` %s &"%tmpfile)
>

We've had this problem for a long time in running system commands.
That's why we have the sage-native-execute script (which does what you
suggest and at least one more thing). The idea behind the
sage-native-execute script is to set the environment back to the system
environment:

https://github.com/sagemath/sage/blob/master/src/bin/sage-native-execute
(see http://trac.sagemath.org/ticket/975)

It certainly can be improved (http://trac.sagemath.org/ticket/9386;
http://trac.sagemath.org/ticket/10286).

Can you try running runsnake with sage-native-execute?

Thanks,

Jason

[Volker Braun]

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

[Rick Graham]

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.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-support/F-yRz60ZgHc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-support+unsubscribe@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

[Jason Grout]

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

[Jason Grout]

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 compiled
by Sage at all---we just invoke the system Octave.

Jason

[Volker Braun]

IMHO that ticket has been done for 2 years. 

There is more to do to get the build system to a sane state, of course. In particular, configure, build, and install phases must be separated for packages. Its not terribly difficult but at this pace we'll live and get hurt by the LD_LIBRARY_PATH thing forever. 

[Volker Braun]

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 as it would if you run it without Sage. 

[Jason Grout]

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