[SciPy-dev] scipy.test() abruptly quits on scipy svn 0.7.0.dev5241

[Peter Norton]

To update my prior problem it seems that I didn't re-build cleanly
enough. I'm not sure I'm getting to the same test now. When I build
the current head with numscons and studio 12 w/ libsunperf, I get a
few linkage problems. I don't believe I get the opportunity to ru
test_linsolve.TestLinsolve this time around. It looks like the C++
compiler isn't linking in libCstd.so:

$ LD_PRELOAD=/usr/local/python/lib/libpython2.5.so /lib/ld.so.1
/usr/local/python-2.5.1/lib/python2.5/site-packages/scipy/sparse/sparsetools/_csr.so
ld.so.1: _csr.so: fatal: relocation error: file
/usr/local/python-2.5.1/lib/python2.5/site-packages/scipy/sparse/sparsetools/_csr.so:
symbol __1cDstdJbad_allocG__vtbl_: referenced symbol not found

$ LD_PRELOAD=/usr/local/python/lib/libpython2.5.so:/usr/local/lib/32/libCstd.so
/lib/ld.so.1 /usr/local/python-2.5.1/lib/python2.5/site-packages/scipy/sparse/sparsetools/_csr.so
Segmentation Fault (core dumped)
(I'm not sure what to make of that core dump under the circumstances,
though). The lack of the mangled alloc call should be manually fixable
with an invocation of CC -G for _csr.so, _csc.so and _coo.so (I think
that' it, though that may change).

In a slightly more problematic case, I don't seem to be getting
dfitpack.so built properly. The symbol "bispeu_" isn't resolved. If
this is just a library ordering issue, can anyone suggest a proper
ordering?

$ objdump -x /usr/local/python/lib/python2.5/site-packages/scipy/interpolate/dfitpack.so
| grep bispeu
00008a4c l     F .text  000005c5 f2py_rout_dfitpack_bispeu
00038770 g     O .data  000001ae .XAV2UeWzL0RJE3G.doc_f2py_rout_dfitpack_bispeu
00038750 g     O .data  00000020
.XBV2UeWzL0RJE3G.f2py_rout_dfitpack_bispeu.capi_kwlist
00000000       F *UND*  00000000 bispeu_

I'm happy to provide most of the details of the build environment
including site.cfg, compiler.cfg, etc. It's possible they are
problematic, however since the build completes successfully I'm not in
a position to declare that it *doesn't* work. Assuming this works
sufficiently, this should be enough for me to test with for now in
spite of the numerous failures in the self tests. It involves fewer
library re-builds than using distutils (libraries get linked without
-G, creating exceutables), though I need to test that out, too.

Thanks,

-Peter

P.S. ATLAS doesn't build on solaris x86 32-bit, which is what I was
hoping I'd be able to do this time to avoid the uncertainty  of
building with libsunperf.