On Feb 7, 2010, at 3:29 AM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
On Feb 6, 2010, at 2:09 PM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
On Feb 6, 2010, at 12:53 PM, Dr. David Kirkby wrote:
Dr. David Kirkby wrote:
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.
Doesn't work in either for me.
It does if you set LD_LIBRARY_PATH first on 't2'
$ export LD_LIBRARY_PATH=/usr/sfw/lib
./sage
import _hashlib
will work.
I've also got _haslib working on the notebook at
http://t2nb.math.washington.edu:8000
try it and see. You will not get the error you used to get.
So you're confirming that this is not a GUI vs CLI issue. That's
good.
No, quite the opposite.
I was saying it was necessary to add something to the
LD_LIBRARY_PATH to get _hashlib to work on the command line, but
despite trying to do this in a startup script, it would not work. I
had to edit 'sage' manually.
I note your later points about not need _hashlib, but irrespective
of that, I think it would be useful if tests could be run in the
GUI. That was the subject of the email, but was prompted by the fact
that I believe its possible for some things to work on the command
line, but not on the GUI.
Sorry, what I was reading was:
- CLI: error
I've seen this.
- CLI + modified LD_LIBRARY_PATH: success
You've confirmed this.
- GUI: error?
This was the original notebook setup, which had errors.
- GUI + modified LD_LIBRARY_PATH: success?
This is the current notebook setup (I tried
os.environ['LD_LIBRARY_PATH']), which works fine.
Ultimately, it seems to me we rely on the front end giving the same
results as at the command line, but never actually testing that. As
I cited with Mathematica, I've known that to give problems with the
graphical front end consuming tons of CPU time, but not at the
command line.
I agree that this is undesirable that there be a difference.
I think it would be advantageous to add /usr/sfw/lib to that
search path, as at least on Solaris 10, it will give some extra
functionality. On OpenSolaris it will not, as the OpenSSL
libraries are not installed by default. When they get installed,
they install in /usr/local/ssl, and python finds them.
If you're referring to #7761, I'm fairly confident that the errors
here had nothing to do with OpenSSL--none of the extension modules
were being compiled correctly because -m64 was not being propagated
to distutils. (It just so happens that we tried to import hashlib,
but importing zlib or something else would have failed as well).
The gnutls bugs at #7387 seemed to boil down to the same issue
(non-64 bit binaries). Whether it was the lack of OpenSSL that was
really causing problems still seems uncertain, I hope they're not,
but who knows.
- Robert
No, I'm not simply referring to #7761. It is very easy to get python
to build in 64-bit mode, by (for example) setting CFLAGS directory
to include -m64. In any case, I've seen this in 32-bit mode (see
below).
That will cause hassles later with cython (possibly other things
too), but we have long since passed the point where building a 64-
bit version of python is problematic.
My point is that although you are able to build Python in 64-bit mode,
the resulting Python may be broken, which is why we have the issues
later on. If "import hashlib" fails, the first thing to do is see if
"import math" fails as well.
I'm less convinced we have passed the point where OpenSSL is not
presenting issues.
Here is part of the log of a 32-bit build on Solaris 10 (SPARC).
Sleeping for three seconds before testing python
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/export/home/drkirkby/sage-4.3.0.1/local/lib/python2.6/
hashlib.py", line 136, in <module>
md5 = __get_builtin_constructor('md5')
File "/export/home/drkirkby/sage-4.3.0.1/local/lib/python2.6/
hashlib.py", line 63, in __get_builtin_constructor
import _md5
ImportError: No module named _md5
real 24m50.923s
user 20m4.386s
sys 3m54.626s
sage: An error occurred while installing python-2.6.2.p4
Then after adding /usr/sfw/lib to LD_LIBRARY_PATH, so the test at
the bottom of spkg-install passes.
Sleeping for three seconds before testing python
hashlib module imported
real 29m35.662s
user 23m29.130s
sys 4m24.886s
Successfully installed python-2.6.2.p4
It looks like hashlib might rely on _md5.
_md5 is a pure C module that is shipped with Python, and does not link
to or rely on anything else. It's built if and only if the ssl headers
are not found (though the logic that handles the imports is rather
ugly). Even with a modified LD_LIBRARY_PATH, import _md5 will still
break.
William, Jaap and I have all has some issues on Solaris with python
not passing the test at the bottom of python's spkg-install on
OpenSolaris, and I've seen it on the first release of Solaris 10 on
SPARC, as shown by the logs above. (But I don't think that has been
consistently the case).
I'm not sure what to make of all this. I'm basically confused!
The above makes perfect sense to me. Python was able to find the
OpenSSL include files (did you add /usr/sfw/include to the build
scripts somewhere?) but not the library files (until you added /usr/
sfw/lib).
If /usr/sfw/include is in the default Solaris paths, but /usr/sfw/lib
is not, it seems that'll be an issue with any libraries there, not
just OpenSSL. If it doesn't find the include files, "import hashlib"
will still work as _md5 will be built, showing that OpenSSL is not a
dependancy.
- Robert
--
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
