Add note on 64-bit build module build problem.

svn path=/pow/README; revision=2686

1 files changed, 28 insertions, 0 deletions

diff --git a/pow/README b/pow/README
index f40f9b34..f234489e 100644
--- a/pow/README
+++ b/pow/README
@@ -20,3 +20,31 @@ uses a few facilities from the other:
   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.