| 1 |
Howdy, |
| 2 |
|
| 3 |
I'm trying to fix the clapack ebuild so it links against _c_blas, not blas. |
| 4 |
(Which, as soon as it works, will remove the fortran dependency for e.g. |
| 5 |
digikam...) |
| 6 |
|
| 7 |
I have a 99.99% working ebuild [*]. It generates a perfectly fine libclapack, |
| 8 |
with one small problem: the libclapack is missing a NEEDED entry for libcblas. |
| 9 |
$ scanelf -n libclapack.so.3.2.1 |
| 10 |
TYPE NEEDED FILE |
| 11 |
ET_DYN libf2c.so.2,libc.so.6 libclapack.so.3.2.1 |
| 12 |
|
| 13 |
Obviously this is a problem, because as soon as another application wants to |
| 14 |
link against libclapack, it "does not know" that it also needs libcblas, and |
| 15 |
ends up with unresolved symbols. If I tell cmake to link against blas, this |
| 16 |
looks fine: |
| 17 |
|
| 18 |
$ scanelf -n /usr/lib64/libclapack.so.3.2.1 |
| 19 |
TYPE NEEDED FILE |
| 20 |
ET_DYN libblas.so.0,libf2c.so.2,libc.so.6 /usr/lib64/libclapack.so.3.2.1 |
| 21 |
|
| 22 |
The relevant cmake code is for cblas (bad): |
| 23 |
|
| 24 |
target_link_libraries(clapack cblas f2c) |
| 25 |
|
| 26 |
and for blas (good): |
| 27 |
|
| 28 |
target_link_libraries(clapack blas f2c) |
| 29 |
|
| 30 |
(one byte difference). Any clue what is going on here? |
| 31 |
|
| 32 |
I have a personal suspicion, namely that libcblas.so is (on my system) |
| 33 |
actually (symlinked to) libgslcblas.so.0, and that maybe cmake reacts because |
| 34 |
the library filename is not equal its SONAME. Does this make sense? And if |
| 35 |
yes, what can I do about it? |
| 36 |
|
| 37 |
Thanks a lot in advance for your help... |
| 38 |
|
| 39 |
Cheers, Andreas |
| 40 |
|
| 41 |
[*] http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=blob;f=sci- |
| 42 |
libs/clapack/clapack-3.2.1-r4.ebuild;hb=HEAD |
| 43 |
|
| 44 |
-- |
| 45 |
|
| 46 |
Andreas K. Huettel |
| 47 |
Gentoo Linux developer |
| 48 |
dilfridge@g.o |
| 49 |
http://www.akhuettel.de/ |
Archives