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

[Peter Norton]

After cleaning up my build, I do end up with the same crash:

............................................................................................................................ESSSSSSSSSSSB->ncol
= 1  Bstore->lda = 5  A->nrow = 5
B->Stype = 5  B->Dtype = 0  B->Mtype = 0
** On entry to sgssv, parameter number 7 has an illegal value.
Segmentation Fault (core dumped)

With verbose=10:

Solve with UMFPACK: double precision ... SKIP: UMFPACK appears not to
be compiled
Solve: single precision ... SKIP: UMFPACK appears not to be compiled
test_twodiags (test_linsolve.TestLinsolve) ... B->ncol = 1
Bstore->lda = 5  A->nrow = 5
B->Stype = 5  B->Dtype = 0  B->Mtype = 0
** On entry to sgssv, parameter number 7 has an illegal value.
Segmentation Fault (core dumped)

-Peter




On Tue, Dec 16, 2008 at 3:23 PM, Peter Norton
<spacey-scipy-dev at lenin.net> wrote:
> 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
>