[Python-Dev] Porting Python 2.4.4. and 2.5 to Sparc Solaris 9 and 10
vancleef at lostwells.net
vancleef at lostwells.net
Wed Feb 14 02:09:43 CET 2007
Dear Python Developers.
I posted the following to the python-help yesterday. While I received
some interesting responses, they indicated that I'd already gone
beyond that group's knowledge, and suggested that I mail the
developers directly on this list.
By way of background, I'm a retired hardware-software engineer with
substantial experience in kernel programming, device drivers, porting
between hardware and software architectures, so am probably more
prepared than the average systems administrator to get into program
details.
I have downloaded the tars for Python 2.4.4 and 2.5, and built both of
them on two Solaris systems, using a variety of compilers. The
original objective was to get a usable Python to support a Mailman
2.1.9 installation. While it was clear that a build of 2.5, using the
Sun Studio 11 development system, was incomplete and did not pass all
of the regression tests, it did prove to be adequate to support
Mailman. I have now come back to audit building Python on Sparc
Solaris and to get some idea of what needs to be done to get a clean
and reasonably complete build.
My attempts to find some support through the Python web site seemed
quite inconclusive. I spent part of a day trying to weave my way
through the Sourceforge bug tracker, but was unable to find anything
that seemed meaningful vis-a-vis what my audits were showing.
Accordingly, I chose to devote some time and effort to determining
where the build problems lay, and what might be needed to fix some of
them.
Build Platform Data:
System A: Sun Ultra 60, Solaris 10 11/06, with Sun Studio 11
development system (/opt/SUNWspro). A Solaris 10 11/06 full
distribution install includes gcc-3.4.3, Python 2.3.3, along with
libraries and header files for such things as Tcl/Tk and openssl.
System B: Sun Ultra 10, Solaris 9 9/05. Development systems are Sun
Studio 11 and a new local build of gcc-4.1.1 (c and c++ only). The
O/S is patched with the mid-January Sun patch cluster. Solaris 9 does
not include a Python or a gcc, but does include Tcl/Tk libraries and
include files.
In both cases, the Studio 11 programs have been patched to current.
The cc patch level is 121015-03.
Both O/S installs are recent "full system" installs on bare machines,
plus the development systems noted. I consider these representative
of what an average systems administrator would have for resources "out
of the box" for building and installing Python from source.
On both systems, the non-Solaris software resides in the /usr/sfw
directory tree.
After having tried several configure/make/make test runs, it appears
to me that there are two problem areas.
1. There is no way in the distribution setup to get the build to find
the /opt/sfw include libraries for building extension modules. It
appears to me that this search is done by setup.py, and that
configuring the appropriate paths in the main Makefile does not
propogate out to the module build. If the configure script has a way
to find these libraries and to set the build up for them, I can't see
what that might be.
This problem affects both 2.4.4 and 2.5.
I have taken the time to add the search code for the Solaris /opt/sfw
directories to setup.py. There were other changes needed to existing
code to get it to work properly. I include a diff between the code
I am using with success and the 2.5 distribution version at the end of
this note. It may not be the most appropriate for distribution, but
it works on Solaris 9 and 10. I had to revise the setup.py in the
2.4.4 distribution similarly.
2. On Python 2.5, the ctypes and libffi code is not only
GNU-specific, but gcc-version-specific as well. The problem with the
__attribute__ specification in ffi.h seems to be well-understood, and
may be amenable to some sort of workaround. However, attempting to
build with the gcc-3.4.3 included with Solaris 10 failed with a linker
misalignment error.
3. Regression test failures:
test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests
I get this output when running make test on any build (Sun cc or any
gcc) on both 2.4.4 and 2.5. Running the ioctl test standalone does
not produce a failure.
At this point, I wonder if I am reinventing the wheel or finding
things that need to be addressed for Solaris builds. I am new to
Python, and while I'd like to use it to make some local changes
to Mailman, I feel concerned over reliability and robustness.
Just how are you getting full Solaris builds?
Hank van Cleef
vancleef at lostwells.net
====================================================================
The test summary and setup.py diffs follow:
280 tests OK.
1 test failed:
test_ioctl
38 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes
test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev
test_macfs test_macostools test_nis test_normalization
test_ossaudiodev test_pep277 test_plistlib test_scriptpackages
test_socket_ssl test_socketserver test_sqlite test_startfile
test_timeout test_unicode_file test_urllib2net test_urllibnet
test_winreg test_winsound test_zipfile64
2 skips unexpected on sunos5:
test_ctypes test_nis
(nis is not enabled on these systems)
Diffs for setup.py:
*** setup.py.dist Thu Feb 8 11:39:42 2007
--- setup.py Mon Feb 12 11:04:44 2007
***************
*** 306,311 ****
--- 306,316 ----
platform = self.get_platform()
(srcdir,) = sysconfig.get_config_vars('srcdir')
+ # Add search directories for Solaris distribution add-ons
+ if platform == 'sunos5':
+ inc_dirs += ['/usr/sfw/include']
+ lib_dirs += ['/usr/sfw/lib']
+
# Check for AtheOS which has libraries in non-standard locations
if platform == 'atheos':
lib_dirs += ['/system/libs', '/atheos/autolnk/lib']
***************
*** 520,529 ****
depends = ['socketmodule.h']) )
# Detect SSL support for the socket module (via _ssl)
search_for_ssl_incs_in = [
'/usr/local/ssl/include',
'/usr/contrib/ssl/include/'
]
! ssl_incs = find_file('openssl/ssl.h', inc_dirs,
search_for_ssl_incs_in
)
if ssl_incs is not None:
--- 525,535 ----
depends = ['socketmodule.h']) )
# Detect SSL support for the socket module (via _ssl)
search_for_ssl_incs_in = [
+ '/usr/sfw/include',
'/usr/local/ssl/include',
'/usr/contrib/ssl/include/'
]
! ssl_incs = find_file('/openssl/ssl.h', inc_dirs,
search_for_ssl_incs_in
)
if ssl_incs is not None:
***************
*** 531,541 ****
['/usr/kerberos/include'])
if krb5_h:
ssl_incs += krb5_h
! ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,
['/usr/local/ssl/lib',
'/usr/contrib/ssl/lib/'
] )
-
if (ssl_incs is not None and
ssl_libs is not None):
exts.append( Extension('_ssl', ['_ssl.c'],
--- 537,546 ----
['/usr/kerberos/include'])
if krb5_h:
ssl_incs += krb5_h
! ssl_libs = find_library_file(self.compiler, 'ssl.so',lib_dirs,
['/usr/local/ssl/lib',
'/usr/contrib/ssl/lib/'
] )
if (ssl_incs is not None and
ssl_libs is not None):
exts.append( Extension('_ssl', ['_ssl.c'],
***************
*** 1245,1251 ****
--- 1250,1258 ----
# Check for various platform-specific directories
if platform == 'sunos5':
include_dirs.append('/usr/openwin/include')
+ include_dirs.append('/usr/sfw/include')
added_lib_dirs.append('/usr/openwin/lib')
+ added_lib_dirs.append('/usr/sfw/lib')
elif os.path.exists('/usr/X11R6/include'):
include_dirs.append('/usr/X11R6/include')
added_lib_dirs.append('/usr/X11R6/lib64')
More information about the Python-Dev
mailing list