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

Peter Norton spacey-scipy-dev at lenin.net
Tue Dec 16 15:23:23 EST 2008


On Tue, Dec 16, 2008 at 1:32 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Peter Norton wrote:
>
>> $ 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
>>
>>
>
> Ahh, that rings a bell. IIRC, I could not find anything wrong with
> either scipy or numscons; I think it is a bug in the sunstudio compiler
> when linking C++ as shared library.
>
>> 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?
>>
>
> The interpolate code has changed recently, it may just be that I have
> not kept up the scons scripts.

Is there a place where I can find the suggested method of updating this?

>> 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.
>
> As far as I am concerned, the C++ problem is a sunstudio bug, so there
> is nothing I can do about it (there are several problems with sun
> compilers with shared libraries, at least on the machine I have been
> using it on: some flags are ignored, or not set up correctly when the -G
> flag is used - I find surprising that something as basic as linking the
> sunperf to a shared library does not work, for example).

It seems that sun doesn't default to automatically linking in the
library for C++, as you say.  I'd prefer to fix this by setting C++
only link flags, but

It looks like scons-local could benefit from having a distinction
between the C linker and the C++ linker, or at least augmenting the CC
linker. In sunlink.py. Adding -lCrun -lCstd to env['SHLINKFLAGS']
doesn't seem to do anything. Is there any chance that scons has a
separate way to pull the flags for a C++ compiler, eg
env['CXXSHLINKFLAGS']?

In the mean time, I'm going to just add -lCrun and -lCstd to LDFLAGS
for everything :(

Thanks,

-Peter



More information about the SciPy-Dev mailing list