Re: [Numpy-discussion] Trouble installing numarray on Solaris

[Russell E O. <rowen@u.washington.edu>]

At 9:10 AM -0400 2005-07-06, Todd Miller wrote:
>One thing I should have mentioned earlier is that numarray has been
>built at STScI using Solaris's cc from the beginning.  Although our
>primary development platform is now x86 Linux, we still ultimately
>deploy to Solaris so I think Solaris cc per-say is probably not the
>problem here. 
>
>Here are the tools I use personally w/o problems:
>
>basil> uname -a
>SunOS anysun.stsci.edu 5.8 Generic_117350-18 sun4u sparc SUNW,Ultra-5_10
>basil> cc -V
>cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02

I asked John for more information and got the following:

--- begin quote ---

First:
The numarray modules (shared library/object files) weren't being
"linked" against any libraries when built, and as a result, any
symbols (functions) that they referenced which are in shared libraries
not already being loaded by python itself would go unresolved whenever
python tried to load the modules.  In particular, my dynamically
linked copy of python (which I compiled from source, btw) isn't linked
against the C math library, so any math functions being used by
numarray were unresolved when the modules were loaded.  The fix was to
add a "-lm" to the command being used to link the module, eg, change:

   cc -G build/temp.solaris-2.7-sun4u-2.3/Src/_ufuncFloat32module.o -o \
   build/lib.solaris-2.7-sun4u-2.3/numarray/_ufuncFloat32.so

to

   cc -G build/temp.solaris-2.7-sun4u-2.3/Src/_ufuncFloat32module.o -o \
   build/lib.solaris-2.7-sun4u-2.3/numarray/_ufuncFloat32.so -lm

With that, now whenever this module gets loaded, the dynamic loader
routines will automatically pull in any required routines from the
math library (libm.so).

Given the time constraints and my lack of python experience, I couldn't
figure out how to feed the standard "python setup.py build" command a
list of libraries to link against, so instead I just let setup.py
build it as is, logged the commands used to create the shared objects,
and then turned the log into a script to relink the objects after
manually added a "-lm" to the end of each link command.

Looking through distutils now, I think I can feed setup.py a
"--libraries" option with the name of the math library, and with that,
it will then build/link the modules correctly.

>  Before I...pass it along, though, I just thought of something: you
>  did specify the --gencode argument, didn't you? The need for that
>  argument is an unwelcome numarray oddity.

Yes I did, although I wasn't sure why that was needed.  BTW, PIL built
OK, and likewise, its modules link against libraries which python
doesn't automatically pull in itself (eg, libjpeg, zlib, etc), so
something in its setup.py is automatically including these libraries
when it builds/links the shared objects.  Another datapoint: I *think*
(or at least it used to be the case) that gcc always includes the math
library when linking, whereas with Sun's (and may other vendors')
compilers, -lm needs to be given explicitly.  In general, I usually
try to compile things with an OS's/vendor's native compilers instead
of gcc, just to keep developers honest (ie, in the interest of weeding
out compiler dependencies/bugs that inhibit source portability). :)
I'm guessing that if I had compiled w/ gcc, I wouldn't have had this
problem.  However, I had compiled python and the other python modules
I have installed with Sun's cc (from Sun's Studio 8 compiler
collection, btw), so for consistency, I wouldn't have wanted to use
gcc anyway.

--- end quote ---

Unless you have any questions, that's the last I'll say on the 
subject. I hope something in here may help track down a bug.

Regards,

-- Russell