On Sun, Jul 20, 2008 at 6:38 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> 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.
Sage should use its own versions of libraries for the reasons you
stated. One exception could be Python,
e.g. there could be an easy way to compile Sage with the systemwide
python, because (imho) Python doesn't change that much, so it could
work in most cases. It works even now.
As chatted on IRC, the LD_LIBRARY_PATH problem *might* get fixed using:
http://packages.debian.org/sid/chrpath
And the other PATH stuff are fixable too.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
