As per summary, feel free to verify...
Still a problem for KDE4 version of digikam, 0.10.0.
Digikam 1.1.0 still has a bundled version of CLAPACK. But, I just can't build CLAPACK on Gentoo. The packages that seems to provide this is sci-libs/lapack-atlas, that depends on sci-libs/lapack-atlas, that takes ages to build and always fails here. So, I couldn't try to unbundled this from digikam.
DigiKam 1.1.0 has: $ ls libs/3rdparty/clapack/ abort_.c close.c dgesv.c dgetrs.c dswap.c err.c fmt.c fp.h ilaenv.c open.c s_copy.c s_stop.c wrtfmt.c blaswrap.h dgemm.c dgetf2.c dlaswp.c dtrsm.c f2c.h fmt.h idamax.c LICENCE README sfe.c util.c wsfe.c clapack.h dger.c dgetrf.c dscal.c endfile.c fio.h fmtlib.c ieeeck.c lsame.c s_cmp.c sig_die.c wref.c xerbla.c
Created attachment 219723 [details, diff] Patch to switch from internal clapack copy to system lapack Please have a look at this - it's my first try... :)
Created attachment 219725 [details] Updated ebuild (new dependencies on virtual/lapack and sys-devel/gcc[fortran])
Anyone from sci interested in adding clapack to the main tree? (Is in overlay...)
I dropped clapack into the tree. please test if it works.
(In reply to comment #7) > I dropped clapack into the tree. please test if it works. > This can't be correct! USE static is not for building static archives, USE static-libs is for that. And the USE dep seems to suggest clapack is requiting the .a to be present instead of linking to the provided .so In other words, this problem just escalated into something much worse than it was... !!! One of the following packages is required to complete your request: - dev-libs/libf2c-20090407 (Change USE: +static) (dependency required by "sci-libs/clapack-3.2.1" [ebuild])
Futhermore, clapack doesn't provide a shared lib at all!
OK, I have to admit I did not look at the clapack ebuild in the overlay before I cc'ed sci. AFAIK, digikam builds fine with the sci-libs/lapack-reference from the main tree. It just requires gcc[fortran] then which may be some sort of overkill. I was hoping we could get around that.
So is clapack included in the lapack-reference?
the the lapack-reference is the fortran code, the clapack is the f2c'ed version of that. What do you need? If it is just the fortran code lib, then it is already provided by virtual/lapack, if you need the c code, then we have to fix the clapack package to provide a shared lib.
http://www.cmake.org/pipermail/cmake/2009-July/030653.html This is the background (from a different package, but identical problem). Summarizing, when CMake checks for lapack, it reqires a Fortran compiler even if we just link against a Fortran-based lib in a c++ program... The other alternative would be to rewrite the FindLAPACK cmake module.
Against which *lapack libs exactly links the current ebuild?
The current ebuild links against an internal copy of clapack; which version that is is not obvious. As I see it there are 3 ways to proceed: 1) Fix sci-libs/clapack to provide a dynamic libary. Work in progress (see bug 309675), but a serious pain. 2) Link against virtual/lapack (the fortran library). This seems to work, see attachment above for ebuild. digikam links and starts up normally, for scanelf output see below. However, it requires a fortran compiler (i.e. gcc[fortran]). (ONLY for the cmake lapack test I think. No fortran code in the build.) 2a) Link against virtual/lapack (the fortran library), and do NOT use cmake's FindLAPACK, but add the library manually somehow. Any cmake gurus around? --------------------------------------------- scanelf output for 2): huettel@pinacolada ~ $ scanelf -n `equery files digikam|grep 'so$'` |grep lapack ET_DYN libkdecore.so.5,libkio.so.5,libkfile.so.4,libkhtml.so.5,libknotifyconfig.so.4,libkdeui.so.5,libkutils.so.4,libsolid.so.4,libQtSql.so.4,libQt3Support.so.4,libjpeg.so.8,libtiff.so.3,libpng12.so.0,libz.so.1,libpgf.so.1,liblcms.so.1,libjasper.so.1,liblapack.so.0,libblas.so.0,libpthread.so.0,libkdcraw.so.8,libkexiv2.so.8,libkipi.so.7,libmarblewidget.so.4,libSM.so.6,libICE.so.6,libX11.so.6,libXext.so.6,libXft.so.2,libXau.so.6,libXdmcp.so.6,libXpm.so.4,libkjs.so.4,libkparts.so.4,libQtNetwork.so.4,libQtXml.so.4,libQtDBus.so.4,libQtSvg.so.4,libQtCore.so.4,libQtGui.so.4,libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1 /usr/lib64/libdigikamcore.so ET_DYN libdigikamcore.so.1,libkio.so.5,libsolid.so.4,libkexiv2.so.8,libkdcraw.so.8,libQtCore.so.4,libpthread.so.0,libQtGui.so.4,libQtSql.so.4,libpgf.so.1,liblapack.so.0,libblas.so.0,libkdeui.so.5,libQtSvg.so.4,libkdecore.so.5,libQtDBus.so.4,libQtNetwork.so.4,libQtXml.so.4,libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1 /usr/lib64/libdigikamdatabase.so huettel@pinacolada ~ $
I ported the patch to 1.2.0 and committed it to the overlay. It definitely works. The perfect is the enemy of the good...
Now in tree. Thanks to all involved!
