On Jul 20, 8:20 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 20, 2008 at 4:48 PM, William Stein <[EMAIL PROTECTED]> wrote:
Hi,
<SNIP>
> BTW, here is another creepy thing, that maybe is a bug in Sage:
>
> $ gedit
> gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
> $
>
> I was just about to report this as a grave bug in Debian, but before I did:
>
> $ ldd /usr/lib/libxml2.so.2
> linux-gate.so.1 => (0xb7f92000)
> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e4e000)
> libz.so.1 => /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7e11000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7cb6000)
> /lib/ld-linux.so.2 (0xb7f93000)
>
> so I just removed the line:
>
> export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib
>
> from my bashrc and all works again. So this is not the way how to
> setup sage. It's actually quite annoying, that you can use either Sage
> or gedit, but not both in the same terminal. Ok, you may say forget
> about systemwide python, just use Sage as it is, take it or leave it.
I am please to say: I told you so. Running Sage with the system python
introduces all kinds of the above crap. And as William pointed out it
is not a bug and we will not fix it since we cannot fix it. There are
myriads of distros out there and no way to make Sage+system Python
work since the libraries they ship are in the end mutually
incompatible. This is one giant quagmire and there is no way out of it
besides using the Debian packages that Tim has been working on.
> Ok, first, it's not the way I'd like to work, but ok, but it won't
> allow me to use gedit either... Try this:
>
> sage: os.system("xclock")
> 0
>
> this works anc xclock comes up, but this doesn't:
>
> sage: os.system("gedit")
>
> ** (gedit:26452): WARNING **: Error initializing Python interpreter:
> could not import pygtk.
>
> ** (gedit:26452): WARNING **: Please check the installation of all the
> Python related packages required by gedit and try again.
>
> ** (gedit:26452): WARNING **: Cannot load Python plugin 'Python
> Console' since gedit was not able to initialize the Python
> interpreter.
> gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
> 32512
>
> I don't know, but I think Sage should not be messing with my system.
Sage is not messing with your system, you *choose* to do things with
LD_LIBRARY_PATH and it blew up in your face. See another "I told you
so" coming? :p
When you launch an application from "proper" Sage that is not
$SAGE_LOCAL/bin it will use the original LD_LIBRARY_PATH. In case
python based applications we might also have to set PATH back to its
original so that the system Python is picked up, but then all the Sage
binaries in $SAGE?LOCAL/bin are not available, so I do not see any
solution that will make everybody happy.
> So this makes me think that maybe exporting the variables so that they
> work in the whole terminal (thus allowing me to use systemwide python)
> is not a good thing, unless there is a robust way to fix the above
> problems.
I think the problem is unfixable. Either way you chose to fix the
issue I can break it. Believe me: I have thought about the issue for a
while :)
> I'll try to investiage the other way round then, e.g.
> setting up paths in sage, so that it imports my systemwide library and
> the current revision of sympy, that I want to test. But I don't like
> this at all, because this makes Sage a full blown application, not a
> library, that can be reused in other projects.
Sage is and never has been meant to be a library in the sense that
Sympy is. In itself Sage is very complex and we want to run on
operating systems besides Debian/Linux, so I see no reason to cater to
any specific distribution of Linux and "just use the system zlib" will
not work everywhere. Sage is self contained for a reason and if we
relied on more components by the system Sage would not work very well.
Just think of the rather large number of combinations when only taken
ten of Sage's components and using the system's instead. I have no
desire to debug such a mess.
You can fix the above issue by skipping the build of zlib by fixing
deps in $SAGE_ROOT/spkg/standard. But that will require rebuilding
Sage from source unless you are willing to remove libz* and the
headers and then rebuild all components of Sage that link against
libz. So a rebuild from scratch in another directory will be quicker
for you since it will take you longer to figure out what to do since
you are not as familiar with Sage's components as I am :)
But even then it will only be a question of time until something else
blows up. That is why I strictly refuse to support Sage being used in
that way in the first place.
> Ondrej
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
