Building Python for Solaris 10 on SPARC

Building python seems to be harder than it ought to be, especially since despite using an autoconf-generated configure script, it is not consistently used.

I want both 32 and 64-bit builds of Python, I want them to co-exist happily in /usr/local and I want shared library versions. Is that too much to ask? Possibly.

Hopefully these notes will help someone else in the future.

Here's the configure command I had to use to get Python 2.4.1 to compile using Sun's Sun Studio 9 compilers:

$ bash ../Python-2.4.1/configure CCSHARED="-KPIC" \
 LDSHARED="cc -xtarget=native -G" LDFLAGS="-xtarget=native" \
 CC="cc" CPP="cc -xtarget=native -E" BASECFLAGS="-xtarget=native" \
 OPT="-xO5" CFLAGS="-xtarget=native" CXX="CC -xtarget=native" \
 --prefix=$HOME/python-32-2.4.1 --enable-shared --without-gcc \
 --disable-ipv6
 

And that was just the 32-bit version.

• I have to run configure from bash rather than the default shell since there's a reliance on test -e which doesn't exist in Solaris sh.
• The CCSHARED is required to make it build with position-independent code, why configure didn't detect this I don't know.
• There appears to be a bug in Sun Studio 9, requiring a plethora of -xc99=none flags to work around problems with configure and Solaris 10 headers, but using Sun Studio 10 fixes that.
• Why BASECFLAGS? I don't know, it's undocumented but it seems required (it seems to be used by the module builder, surely this should be documented!).

Then it's the usual:

$ gmake -j 6
$ gmake test
$ gmake install
 

to build and install (getpwd fails the test for some reason).

To get a 64-bit version to build here's the configure command:

$ bash ../Python-2.4.1/configure CCSHARED="-KPIC" \
 LDSHARED="cc -xtarget=native64 -G" LDFLAGS="-xtarget=native64" \
 CC="cc" CPP="cc -xtarget=native64 -E" \
 BASECFLAGS="-xtarget=native64" OPT="-xO5" \
 CFLAGS="-xtarget=native64" CXX="CC -xtarget=native64" \
 --prefix="$HOME/python-64-2.4.1/64" --enable-shared \
  --without-gcc --disable-ipv6
 

Note the similarity with the previous 32-bit configure, except:

• I've used a different prefix, so the 32-bit and 64-bit versions can be tested separately before being combined with stow.
• In fact, the prefix is now completely independent of all 32-bit programs. Try as I might, several times, over several days, I simply could not make a multi-arch build that would live together happily (e.g., using the with-suffix=-64, libdir and includedir options, setting LIBDIR etc manually).
• I don't use --exec-prefix since the Python Makefile has hard-coded expansions for some variables. For example the pyconfig.h header and the libpython2.4.so library are installed in precisely the wrong place, instead of paying attention to configure arguments of libdir and includedir. It does this because the Makefile.pre.in they have the following:

  LIBDIR=  $(exec_prefix)/lib
  MANDIR=  @mandir@
  INCLUDEDIR= @includedir@
  CONFINCLUDEDIR= $(exec_prefix)/include
  SCRIPTDIR= $(prefix)/lib
       

  So you cannot override the locations of LIBDIR, CONFINCLUDEDIR, and SCRIPTDIR to be precisely where they should be.

There is also a bug in the build scripts, with an easy fix:

--- Lib/distutils/command/build_scripts.py~     2004-11-11 09:23:15.000000000 +1100
+++ Lib/distutils/command/build_scripts.py      2005-06-15 12:50:51.925373000 +1000
@@ -104,7 +104,7 @@
                        outf.write("#!%s%s\n" %
                                   (os.path.join(
                            sysconfig.get_config_var("BINDIR"),
-                            "python" + sysconfig.get_config_var("EXE")),
+                            "python" + str(sysconfig.get_config_var("EXE"))),
                                    post_interp))
                    outf.writelines(f.readlines())
                    outf.close()
 

This is probably because the suffix -64 is interpereted as a number. This doesn't really matter to me anymore since I now install in a completely separate prefix which is independent of all 32-bit programs.

The build, test and install also required some rejigging, thanks to the hard-coded value of (undocumented) RUNSHARED (rather than being configurable).

$ gmake -j 6 RUNSHARED="LD_LIBRARY_PATH_64=`pwd`"
$ gmake RUNSHARED="LD_LIBRARY_PATH_64=`pwd`" test
$ gmake RUNSHARED="LD_LIBRARY_PATH_64=`pwd`" install
 

LD_LIBRARY_PATH_64 is the Solaris 64-bit linker library path.

I then create symlinks so the 64-bit binaries are available:

$ cd $HOME/python-64-2.4.1
$ mkdir bin
$ cd bin
$ ln -s ../64/bin/python python-64
$ ln -s ../64/bin/python2.4 python2.4-64
 

Both 32 and 64-bit packages are stow-ed into /usr/local.

Since the 64-bit package puts the shared libraries in a new directory we have to add this directory to the runtime linking path:

# crle -64 -u -l /usr/local/64/lib