Robert Bradshaw wrote:
On Jan 31, 2010, at 4:01 AM, Dr. David Kirkby wrote:
But I can see no justification for letting someone try to build Sage,
for it to fail a couple of hours later, in a way we could have
predicted in less than a minute.
I think the 'prerequ' configure script should check for OpenSSL and
exit if it is not present, since we can be 100% sure Sage will not
build without it. Exactly what error message is produced would need to
be discussed. But it's crazy for 'prereq' to not check for it. Just as
it would be crazy to not check for perl, when we know it is needed.
I've recently updated 'prereq' to try to ensure that people are made
aware of build issues before they start.
* gcc too old.
* perl too old.
* gcc/g++/gfortran not all the same version
* not a mix of GNU and non-GNU compilers
etc etc.
To me, checking for OpenSSL support should be added to that list,
since it is a requirement to build Sage.
Whatever the long term solution for OpenSSL/crypto support, I certainly
agree that, as things stand now, adding it to prereq is better than a
build that fails half way through.
- Robert
Thank you Robert.
I checked the python source code, and found it searches two directories for the
libraries, in addition to the normal search path. It has this bit of code in the
top-level setup.py.
----------------------------------------------
ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,
['/usr/local/ssl/lib',
'/usr/contrib/ssl/lib/'
] )
---------------------------------------------
I have submitted an RFE to the Python bug list
http://bugs.python.org/issue7836
and suggest they add /usr/sfw/lib to that list, as that is where the libraries
are installed on Solaris.
What I propose we do in Sage is:
1) Modify the setup.py of python so it also searches for libssl.so in
/usr/sfw/lib, which will find the libraries on Solaris 10. That is ticket
http://trac.sagemath.org/sage_trac/ticket/8152
but I'm not going to bother doing that, until there is agreement over this.
2) Search for libssl.so in the standard directories, which the linker looks in
(/usr/lib etc)
3) Search for libssl.so in the two directories searched for by python now
(/usr/local/ssl/lib and /usr/contrib/ssl/lib/) AND in /usr/sfw/lib.
If OpenSSL is not found in any of those locations, then we should exit with a
message:
----------------------------------------------------------
Unable to find the OpenSSL libraries, which are usually part as part of the
operating system. However, the location of the OpenSSL installation does vary
with between different platforms. Please set LD_LIBRARY_PATH to the location of
the directory containing your OpenSSL libraries (libssl.so)
----------------------------------------------------------
(I would propose using that exact wording. Feel free to comment on it, change
it, but let's agree on the exact wording of the error message, since it is
important).
With the above wording, we are *not* explicitly telling someone to
install OpenSSL, just to set LD_LIBRARY_PATH to where OpenSSL is installed.
I just checked my HP-UX system (flames to /dev/null) and OpenSSL is installed
somewhere else on that. So it's not unreasonable to say that people should set
LD_LIBRARY_PATH to the location of their OpenSSL libraries. It varies from
system to system.
Can we have any agreement on this?
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
