Summary: | sci-libs/lapack-atlas-3.9.23-r1 has undefined symbols | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jean-Francis Roy <jeanfrancis> |
Component: | Current packages | Assignee: | Justin Lecher (RETIRED) <jlec> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | flameeyes, sci |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 308611 | ||
Attachments: |
build.log from emerging scipy
possible fix for missing symbols issue |
Description
Jean-Francis Roy
2010-03-09 04:00:45 UTC
Created attachment 222769 [details]
build.log from emerging scipy
This version is masked for some reasons. Yep it is now. For some reason it wasn't as Portage tried to upgrade to it. Maybe a bad sync (if it's possible) as I didn't play with package.unmask for that package. Should this bug then be marked as invalid? No keep it to remind me to be carefull when doing such tings! :) Actually I don't know what is going wrong. But I will find it out. (In reply to comment #4) > No keep it to remind me to be carefull when doing such tings! :) Actually I > don't know what is going wrong. But I will find it out. > One of the seds screws up our ar wrapper (war) resulting in symbols not being added to the final libs. I've attached a fix below. cheers, Markus Created attachment 223243 [details, diff]
possible fix for missing symbols issue
Hi markus thanks for the patch. Nevertheless, blas-atlas screws up in case of rising the EAPI. I have to figure out at which points it happens. after that I will unmasked and fix lapack-atlas. (In reply to comment #7) > Hi markus thanks for the patch. Nevertheless, blas-atlas screws up in case of > rising the EAPI. I have to figure out at which points it happens. after that I > will unmasked and fix lapack-atlas. > Both -r1 versions of blas-atlas and lapack-atlas work just fine for me. Initially the -r1 of blas-atlas was broken as well since it had the same "war" issue than the lapack-atlas patch above fixes. I am a little puzzled about this since the version in cvs is good. Maybe some of the mirrors picked up something bad? In any case the -r1 of blas-atlas that is currently in cvs should work just fine. Maybe diff against your current version in /usr/portage and see if they differ. BTW, a very good way to test new blas and lapack-atlas ebuild is to run the test suite of itpp which is very comprehensive (I do this every time I do sth to any of the atlas ebuilds). If it passes your likely in pretty good shape. cheers, Markus There must be something different. I found some major changes in the headers (not just little differences in the estimated timings) and the is additionally the clapack.h installed with blas.atlas, which isn't in the 3.9.23 version. *** Bug 313669 has been marked as a duplicate of this bug. *** Correcting typo on new title ;-) Should be fixed, if not please reopen. |