Howdy, I'm trying to fix the clapack ebuild so it links against _c_blas, not blas. (Which, as soon as it works, will remove the fortran dependency for e.g. digikam...)
I have a 99.99% working ebuild [*]. It generates a perfectly fine libclapack, with one small problem: the libclapack is missing a NEEDED entry for libcblas. $ scanelf -n libclapack.so.3.2.1 TYPE NEEDED FILE ET_DYN libf2c.so.2,libc.so.6 libclapack.so.3.2.1 Obviously this is a problem, because as soon as another application wants to link against libclapack, it "does not know" that it also needs libcblas, and ends up with unresolved symbols. If I tell cmake to link against blas, this looks fine: $ scanelf -n /usr/lib64/libclapack.so.3.2.1 TYPE NEEDED FILE ET_DYN libblas.so.0,libf2c.so.2,libc.so.6 /usr/lib64/libclapack.so.3.2.1 The relevant cmake code is for cblas (bad): target_link_libraries(clapack cblas f2c) and for blas (good): target_link_libraries(clapack blas f2c) (one byte difference). Any clue what is going on here? I have a personal suspicion, namely that libcblas.so is (on my system) actually (symlinked to) libgslcblas.so.0, and that maybe cmake reacts because the library filename is not equal its SONAME. Does this make sense? And if yes, what can I do about it? Thanks a lot in advance for your help... Cheers, Andreas [*] http://git.overlays.gentoo.org/gitweb/?p=user/dilfridge.git;a=blob;f=sci- libs/clapack/clapack-3.2.1-r4.ebuild;hb=HEAD -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
