$Id$

This is a hacked version of the Python OpenSSL Wrappers (POW) package.
At some point I'll package up the changes and send them to the package
maintainer (if I can find him), but I want my changes under version
control while I'm hacking.

POW is a nice package, although it appears not to have gotten much
attention recently.  It's really two separate packages, one of which
uses a few facilities from the other:

- POW itself is a Python extension module linked against OpenSSL.
  This (or some equivilent package like M2Crypto) is necessary if one
  wants to use the various crypto algorithms.

- POW.pkix is a pure-Python module that builds on the base POW module
  to support X509v3 extensions.  This, to me, is the most interesting
  thing about POW: it's the only X.509 package for Python I've seen
  that has a reasonably complete mapping of X.509v3 into native Python
  datatypes (M2Crypto, by comparision, only supports the text
  representations provided by the extension drivers in the OpenSSL
  libraries -- POW supports those too, but they're not as useful).

===

At present the POW extension module does not build cleanly on 64-bit
Intel-based systems using the GNU tool chain (eg, Linux on 64-bit
hardware) due to a problem in the compilation tool chain.  The details
are obscure and nasty, but the short version is that the 32-bit tool
chain supports building a .so file with static (.a) library as one of
the inputs, while the 64-bit tool chain does not; this problem is
compounded by a combination of the baroque OpenSSL build system and
the highly automated Python extension module build system.

The (vile, temporary) workaround is to build everything with shared
libraries instead of static libraries and install a 3779-enabled set
of OpenSSL shared libraries in the system library directory so that
the Python extension module can find them.  This is (sort of) ok if
you don't mind having the 3779-enabled OpenSSL libraries installed,
but as this code was intended to be self-contained without whacky
dependencies like this, it's not what I would wish.

There is probably some set of kludges we can insert into the build
process (eg, a "ld -r" hack) to work around this, but we haven't taken
the time to figure out what it is yet.

The test for whether your system has this problem is simple: try
running "make" in the top-level directory.  If it blows up trying to
build the POW extension module, you have this problem; if nothing
obviously bad happens, you're (probably) ok.