problem with FFT module from Numeric 20.2.0

[P. Alejandro Lopez-Valencia]

In article <GKqD58.9Ko at leeds.ac.uk>, nde at comp.leeds.ac.uk says...
>I'm trying to build a working Numeric 20.2.0 from source using
>GCC 3.0 on a Linux system running Python 2.1.  Python is also
>compiled with GCC 3.0.  Numeric itself seems to work - at least,
>the tests all pass - but the FFT module is causing problems:
>
>  >>> import FFT
>  Fatal Python error: can't initialize module fftpack
>  Abort
>
>Can anyone offer an explanation or suggest a possible fix?

This kind of thing is the domain of the sun-managers list :) Yet, I am 
sure it will show up more and more as people migrate from crappy gcc 
2.9.x to 3.x.

Due to a bug in Python's autoconf setup, you'll have to this by hand. 
If compiling a new copy of Python under Solaris, the procedure is to run 
configure, add the fix to config.status and Makefile.pre and regenerate 
the Makefiles.

GCC 3.x under Solaris compiles its runtime library as a shared object 
and place it in /usr/local/lib/libgcc_s.so. As well, the native ld(1) 
linker (you don't want to use another at all) doesn't hard link the 
library search path unless explicitly told. Instead, the  shared objects 
stub library reads the contents of the environment variable 
LD_LIBRARY_PATH at runtime.

The solution is to be explicit. Edit your file 
/usr/local/lib/python21/config/Makefile in the appropriate places (3,  I 
don't recall their names off-had) to pass -R linker flags to ld. For 
example, I have added this in our lab box:

 -R/usr/lib -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/openwin/lib

Without these linker flags modules like socket and pyexpat won't work at 
all if called from restricted execution environments where you don't 
want a full environemnt definition, namely CGI's and batch jobs.


-- 
P. Alejandro Lopez-Valencia

Kenkon Itteki       ---       Heaven and Earth at one stroke