problem with showing plots from command line
Jonathan Bober
I tried to send the following email a few hours ago (but I put the email
address in wrong) and I don't feel like rewriting it all. So I should
add to it now that I have upgraded sage (so I am running 2.8.8.1) and
the error still occurs.
Perhaps I should open a ticket for this, but perhaps I should also wait
to see it anyone else can duplicate this problem.
---------------------------------------------------------------------
Hi all.
I apologize for not upgrading to the latest version of sage before
writing this email, but I didn't see any tickets about this on the since
2.8.7.2, so perhaps no one else has had this problem. (And I am
upgrading now, but if I don't send this email now, I might forget about
it for a few days).
Anyway, the following takes place on a Intel Core Duo (not Core 2, so
just 32 bits) newly upgraded to Ubuntu 7.10, and running sage 2.8.7.2.
Briefly, plot().show() isn't working for me. After looking into the
problem a little bit, I modified the code for show() so that it would
print out the command line that it was using, along with any errors. I
get the following:
sage: f(x) = x*exp(-4*x)
sage: P = f.plot()
sage: P.show()
xdg-open /home/bober/.sage//temp/bober/11314//tmp_0.png &
sage: eog: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol:
gzopen64
So there is some sort of library problem. But if I execute the same
command from a plain shell:
bober@bober:~$ xdg-open /home/bober/.sage//temp/bober/11314//tmp_0.png
eog opens the file just fine. So it seems that sage is somehow screwing
up library search paths, or perhaps when eog is run from within sage it
is trying to use some libraries that sage provides and some libraries
that Ubuntu provides, and those libraries don't play nice together. Or
something like that is going on.
plot().show() also does not work anymore for me when running sage 2.8.2,
and it certainly used to before I upgraded Ubuntu, so it is probably
safe to assume that it is getting the same error, and that this error
was caused by the upgrade. (I haven't actually taken the time to verify
that eog gives the same library error when run from 2.8.2, however.)
This is probably beyond my ability to debug any further without spending
many hours, so hopefully someone knows how to fix this easily, or can at
least point me in the right direction.
mabshoff
On Oct 23, 8:20 am, Jonathan Bober <jwbo...@gmail.com> wrote:
> Hi folks.
Hello Jonathan,
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.
>
> So there is some sort of library problem. But if I execute the same
> command from a plain shell:
>
> bober@bober:~$ xdg-open /home/bober/.sage//temp/bober/11314//tmp_0.png
>
> eog opens the file just fine. So it seems that sage is somehow screwing
> up library search paths, or perhaps when eog is run from within sage it
> is trying to use some libraries that sage provides and some libraries
> that Ubuntu provides, and those libraries don't play nice together. Or
> something like that is going on.
>
> plot().show() also does not work anymore for me when running sage 2.8.2,
> and it certainly used to before I upgraded Ubuntu, so it is probably
> safe to assume that it is getting the same error, and that this error
> was caused by the upgrade. (I haven't actually taken the time to verify
> that eog gives the same library error when run from 2.8.2, however.)
>
> This is probably beyond my ability to debug any further without spending
> many hours, so hopefully someone knows how to fix this easily, or can at
> least point me in the right direction.
Cheers,
Michael
David Joyner
This works for mebut it opens up gimp (ubuntu 64bit) and previewer
(intel macbook) as the graphics viewer, instead of a separate
tab of firefox which is what it did before.
I actually prefer the new behaviour (it makes my workflow a bit more
efficient), but agree with you that something seems to have changed.
Out of curiosity, is gimp installed on your system?
Jonathan Bober
> 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.
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. 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
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.)
output from ldd /usr/bin/eog, just in case there is something I missed:
linux-gate.so.1 => (0xffffe000)
/usr/lib/fglrx/libGL.so.1.2.xlibmesa (0xb7ee9000)
libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7d9a000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d81000)
libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0xb7d69000)
liblaunchpad-integration.so.0 => /usr/lib/liblaunchpad-integration.so.0 (0xb7d65000)
libgnome-desktop-2.so.2 => /usr/lib/libgnome-desktop-2.so.2 (0xb7d50000)
libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0xb7cc4000)
libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0xb7c6a000)
libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0xb7c55000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb7c3f000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7c0d000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7c08000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7883000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb77fb000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb77e3000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb776c000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb767b000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7677000)
libexif.so.12 => /usr/lib/libexif.so.12 (0xb764d000)
liblcms.so.1 => /usr/lib/liblcms.so.1 (0xb761b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb75f6000)
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xb75db000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb75a0000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb74e3000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb74c3000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7378000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb725a000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb724c000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7247000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7244000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb723f000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb723a000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7230000)
libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb722c000)
/lib/ld-linux.so.2 (0xb7f4c000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7211000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7208000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb71dc000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb71d4000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb71d1000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb71c9000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb71c3000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb71ba000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb71b6000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7179000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7171000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7159000)
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0xb70fb000)
libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0xb70ca000)
libpopt.so.0 => /lib/libpopt.so.0 (0xb70c2000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0xb7066000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0xb7051000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb6ffe000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb6ff5000)
libstartup-notification-1.so.0 => /usr/lib/libstartup-notification-1.so.0 (0xb6feb000)
libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 (0xb6fdd000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb6fa8000)
libgnutls.so.13 => /home/bober/sage-2.8.7.2/local/lib/libgnutls.so.13 (0xb6f0f000)
libavahi-glib.so.1 => /usr/lib/libavahi-glib.so.1 (0xb6f0b000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb6f00000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb6ef1000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb6ede000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb6ec8000)
libesd.so.0 => /usr/lib/libesd.so.0 (0xb6ebd000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb6e9b000)
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)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6df0000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6deb000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6dd3000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6da4000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6d84000)
libgailutil.so.18 => /usr/lib/libgailutil.so.18 (0xb6d7c000)
libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 (0xb6d77000)
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)
libsepol.so.1 => /lib/libsepol.so.1 (0xb6ce0000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb6c1a000)
mabshoff
On Oct 23, 6:04 pm, Jonathan Bober <jwbo...@gmail.com> 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
Jonathan Bober
I listed the component as "distribution" because I am guessing that that
is supposed to mean "issues with how the different parts of sage are all
put together", but I'm not sure if that is correct.
Thanks.