[mod_python] Mod_python on HP-UX 11.11

> >         /opt/imake/bin/install -c -d /wwimacs6/apache2/modules
> > rm: /wwimacs6/apache2/modules/ directory
> > cp: illegal option -- d

The "install" that comes with imake (a really old build
system for X Window System) does not conform to the
the same options that the GNU install program does.
Unfortunately that's the only thing that comes with HP-UX,
so the autoconfigure scripts will try to use it.  Sometimes
it works and sometimes it doesn't.

You can either copy the files manually, or the best
option if you compile a lot of open source software is
to install the GNU version (it's in the "coreutils" package
these days).  http://www.gnu.org/software/coreutils/

In fact to make life happier I typically always install the
GNU versions of these before bulding much of anything
else: install, gmake, libtool


> > This is all that is in .libs after the make install and I end up with no
> > .so file
> >
> > -rw-r--r--   1 root       sys         161346 Nov 15 20:39 mod_python.a
> > lrwxr-xr-x   1 root       sys             16 Nov 15 20:39 mod_python.la
> > -> ../mod_python.la
> > -rw-r--r--   1 root       sys            848 Nov 15 20:39 mod_python.lai
> > -rwxr-xr-x   1 root       sys         188416 Nov 15 20:39 mod_python.sl
>
> The mod_python.sl file is what you are after. The libtool program looks
> not to be generating .so extension because of HPUX using a .sl extension.

Graham's right, rename the *.sl to *.so should work.

HP-UX uses a default *.sl extension for all shared libraries, as
well as shared objects (there's really no difference for 32-bit
SOM format).  For 64-bit HP-UX uses ELF, but still keeps the *.sl
convention.  The older Apache/libtool you have just aren't passing
all the options to the linker to make it use the alternate names.

However you can name the file anything you want, so just rename
it from *.sl to *.so.  The linker (ld) won't know what a *.so file is,
but Apache loads modules using the dlopen(3) calls, not ld, and
it is Apache which is expecting the file to have a *.so extension.

Since you're having to manually install the library, you may want
to check the file for dependencies first.  libtool will typically
re-link all shared libraries/objects during the install phase so
what you find in the build .libs directory may not be exactly what
you would get after the install phase.

To see if you're okay, do the following command on the library:

    chatr  mod_python.sl

Among the output you'll see any dynamic dependencies on
additional libraries.  You want to check for any libraries other
than the standard system ones (in /usr/lib).  In particular see
if there is a dependency on libpython* or any other non-HP
libraries.  I don't know if you'll see them or not, but if you do
check out if the references have the correct embded paths
to where the libraries are actually installed and not to where
you happened to build them.

If you don't know how to interpret the chatr output and are
still having problems post the output of chatr here.


One thing you may definitely want to try/test is that the
chained shared loading works.  Remember that Apache
loads shared objects dynamically, but so does Python.
So you can have a case where apache loads mod_python,
which then because of some import statement of a
C-extension module will then dynamically load another
shared object (from the python lib).  So to test that all
your dynamic linking stuff is working, write a simple
mod_python handler which imports some C-based python
module such as cStringIO (assuming your Python was
built to have it as a loadable module).  Look in the python
lib-dynload directory of your Python installation for
candidate modules to try.

Finally, also be aware of any potentially conflicting shared
objects/libraries that Apache vs. Python use.  Typical
potential conflicts are with zlib (libz) or the SSL libs
(libcrypto, libssl).  Make sure everything is linking against
the exact same versions of everything.


BTW, this is not a mod_python issue, but just so you
know there was an HP-UX specific bug in Apache 2.0.x
with the regex libraries; it would use HP's libraries thinking
they were POSIX regex compatible, but they weren't...
causing many Apache regex-based directives to fail
(such as <FileMatch>).   I filed a bug report/patch ages
ago and this seems to no longer be a problem with the
Apache 2.2 branch.
-- 
Deron Meranda