On Oct 23, 6:04 pm, Jonathan Bober <[EMAIL PROTECTED]> wrote:
> > Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg-
> > open' with and without sourcing sage-env. If you add an 'echo
> > LD_LIBRARY_PATH' right before xdg-open is called in P.show()
>
> > >From the name of the symbol I would guess that it is a libz
> > incompability. There was a patch to the launch code for firefox/
> > iceweasel that malb made because of a similar issue. Maybe we need to
> > reset LD_LIBRARY_PATH to the old value before we modify it in sage-env
> > in case we launch external helper applications.
>
Hello Jonathan,
> LD_LIBRARY_PATH (right before xdg-open is called) is
>
> /home/bober/sage-2.8.7.2/local/lib/openmpi:/home/bober/sage-2.8.7.2/local/lib/:
>
> It isn't actually set to anything normally (outside of sage-env),
> however. ldd xgd-open won't tell anything (actually, it says that it
> isn't a dynamic executable) because xdg-open just launched the preferred
> application.
Ok, that is to be expected since I didn't know xgd-open was a script.
> However, when executed from within sage, ldd /usr/bin/eog
> yields the following possibly offending lines. (The full output is at
> the end of this email.)
>
> libgnutls.so.13 => /home/bober/sage-2.8.7.2/local/lib/libgnutls.so.13
> (0xb6f0f000)
> libfreetype.so.6 =>
> /home/bober/sage-2.8.7.2/local/lib/libfreetype.so.6 (0xb6e36000)
> libz.so.1 => /home/bober/sage-2.8.7.2/local/lib/libz.so.1 (0xb6e20000)
> libpng12.so.0 => /home/bober/sage-2.8.7.2/local/lib/libpng12.so.0
> (0xb6df3000)
> libgcrypt.so.11 => /home/bober/sage-2.8.7.2/local/lib/libgcrypt.so.11
> (0xb6d25000)
> libgpg-error.so.0 =>
> /home/bober/sage-2.8.7.2/local/lib/libgpg-error.so.0 (0xb6d21000)
>
> I realize now that I don't have to go through all of this source editing
> to find the problem:
>
> sage: !eog
> eog: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
>
> sage: !gimp
> gimp: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol:
> FT_Library_SetLcdFilter
>
> sage: !gvim
> gvim: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol:
> FT_Library_SetLcdFilter
>
Yep, all those are errors due to libraries that are in $SAGE_LOCAL/
lib, but have imcompabilities with the system libraries.
> And the problem extends beyond library path errors into python path
> errors:
>
> sage: !glchess
> Traceback (most recent call last):
> File "/usr/games/glchess", line 18, in <module>
> from glchess.glchess import start_game
> ImportError: No module named glchess.glchess
>
> However, calling
>
> os.system("LD_LIBRARY_PATH='' eog")
> or
> os.system("LD_LIBRARY_PATH='' gimp")
>
> works just fine, so a solution might be to just unset LD_LIBRARY_PATH
> before calling external applications. But there might be a better
> solution, because I would like for "!eog" to work, for example. (Well,
> that's not something that I ever use, but it should work anyway.)
>
The problem is that application like singular would fail if
LD_LIBRARY_PATH was unset. One solution would be to come up with a
white list of applications that are "Sage internal" or alternatively
check if in case we do '!foo' whether there is a foo in $SAGE_LOCAL/
bin and execute with LD_LIBRARY_PATH or alternatively if foo isn't in
$SAGE_LOCAL/bin execute with the old LD_LIBRARY_PATH before sage-env
changed it [and not with an empty one!]
> output from ldd /usr/bin/eog, just in case there is something I missed:
>
<SNIP>
Please open a ticket for this issue.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
