| Summary: | sci-libs/scipy-0.6.0-r2: scipy.test(1) gives a segmentation fault with lapack-atlas | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Lars Bittrich <lars.bittrich> |
| Component: | [OLD] Library | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Lars Bittrich
2007-10-30 15:24:52 UTC
Thanks for your note and I can confirm this problem on my box. So it looks like that even though the clapack patch allows to link against lapack reference the actual functions that are being linked against are either broken or more likely not the proper ones. The only remedy I see at present would be to remove the patch and have scipy hard-depend against blas-atlas (which has the proper symbols) and possibly mkl, acml. I'll have to look into this some more. Thanks, Markus (In reply to comment #1) > Thanks for your note and I can confirm this problem > on my box. So it looks like that even though the clapack > patch allows to link against lapack reference the actual functions > that are being linked against are either broken or more likely > not the proper ones. The only remedy I see at present would > be to remove the patch and have scipy hard-depend against > blas-atlas (which has the proper symbols) and possibly mkl, acml. > I'll have to look into this some more. > > Thanks, > Markus > I had a little closer look and the clapack patch indeed seems to be incorrect. It was intended to allow scipy to compile against lapack-reference. However, the real issue is that scipy needs clapack (an f2c'd version of lapack) which lapack-atlas provides and lapack-reference doesn't. The clapack patch simply forces scipy to link against the fortran symbols which - not too surprisingly - causes trouble. Hence, it seems that unless the clapack part can somehow be disabled in scipy itself we need lapack-atlas (or other lapack implementations that provide clapack). Does anybody with detailed scipy knowledge have any good suggestions? Otherwise I'll probably have to bump scipy to -r3 with that patch removed again. cheers, Markus > I had a little closer look and the clapack patch indeed seems to be > incorrect. It was intended to allow scipy to compile against > lapack-reference. However, the real issue is that scipy > needs clapack (an f2c'd version of lapack) which lapack-atlas provides > and lapack-reference doesn't. The clapack patch simply forces > scipy to link against the fortran symbols which - not too surprisingly - > causes trouble. Hence, it seems that unless the clapack part can > somehow be disabled in scipy itself we need lapack-atlas (or other > lapack implementations that provide clapack). > Does anybody with detailed scipy knowledge have any good suggestions? > Otherwise I'll probably have to bump scipy to -r3 with that patch > removed again. If I remember, scipy auto-adapts the lapack version: if lapack only has F77 bindings, it will create the clapack ones, if not, as in the case of lapack-atlas, it will use them. Removing the patch should fix the issue, but we need to be careful to not reproduce bug #195619. Sébastien patch reverted. |
