Robert Bradshaw wrote:
On Feb 6, 2010, at 3:58 AM, Dr. David Kirkby wrote:
I've noticed an issue at
http://t2nb.math.washington.edu:8000/
where something fails when using the GUI, but which works at the
command line.
import haslib
Are you sure that's not a typo? You probably want hashlib (which should
work regardless of OpenSSL being found). I'd be really surprised if
"import haslib" (missing h) worked anywhere.
Hi Robert,
yes, you are correct, it was a typo. It is actually
"import _hashlib"
which causes the problem. It works at the command line, but not in the browser.
For reasons unknown, I suspect the LD_LIBRARY_PATH is not being seen when this
starts at boot time. I've asked on comp.unix.solaris, and nobody can understand
why LD_LIBRARY_PATH does not work.
First, if I do nothing, I get the message:
ImportError: ld.so.1: python: fatal: libssl.so.0.9.7: open failed: No
such file or directory
If I copy libssl.so.0.9.7 into $SAGE_ROOT/local/lib, then I get the message
ImportError: ld.so.1: python: fatal: libcrypto.so.0.9.7: open failed: No
such file or directory
So it has found libssl, but not libcrypto. As soon as I copy
/usr/sfw/lib/libcrypto.so.0.9.7
to $SAGE_ROOT/local/lib
so _hashlib will import properly, with no error message.
So somehow I need to get Sage to know about the LD_LIBRARY_PATH.
If I edit the the 'sage' directly, and just add at the top
export LD_LIBRARY_PATH=/usr/sfw/lib
so the libraries get found ok. So there are two ways around this issue
1) Manually edit 'sage' and add
export LD_LIBRARY_PATH=/usr/sfw/lib
2) Copy the libraries over to $SAGE_ROOT/local/lib.
So I can solve the issue, but neither are totally satisfactory. Both work, but
neither neither are very good.
It would not be so bad if I could guarantee the libraries would only be there,
but if someone has installed OpenSSL, then the libraries (probably newer
versions) would be in /usr/local/ssl.
One possible option is to add /usr/sfw/lib to the list of directories Python
searches for the libraries. That is set in python's top-level setup.py. I've
made that
http://trac.sagemath.org/sage_trac/ticket/8152
While that will work at compile time, so Sage should compile reliably, I'm not
sure it will work at run-time. I've not checked that. Either way, I think it is
worth adding /usr/sfw/lib to the list of directories were python looks for the
libraries.
Anyway, regardless of this particular issue with OpenSSL, the fact remains that
it is possible under some circumstances for Sage to work properly at the command
line, but not in the notebook. So some method of testing under the conditions
most people use Sage (i.e. the notebook), would be useful.
I know OpenSSL is causing a problem, but I've no idea if something else does not
break too, unless I can run the tests with my browser.
dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
