Bug 295423 - External libclapack not used [patch]
Summary: External libclapack not used [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Portability-Runtime (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-06 16:20 UTC by nucleo
Modified: 2013-03-30 18:45 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 3.2.0


Attachments
patch fixes build against external libclapack (1.57 KB, patch)
2012-03-06 16:23 UTC, nucleo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nucleo 2012-03-06 16:20:46 UTC
User-Agent:       Opera/9.80 (X11; Linux i686; U; ru) Presto/2.10.229 Version/11.61
Build Identifier: 

External libclapack not detected without this patch:

diff -ur digikam-2.1.1/core/cmake/modules/FindCLAPACK.cmake digikam-2.1.1-clapack-atlas/core/cmake/modules/FindCLAPACK.cmake
--- digikam-2.1.1/core/cmake/modules/FindCLAPACK.cmake	2011-09-14 08:22:02.000000000 +0200
+++ digikam-2.1.1-clapack-atlas/core/cmake/modules/FindCLAPACK.cmake	2011-09-23 07:09:37.000000000 +0200
@@ -27,7 +27,7 @@
      endif(CLAPACK_INCLUDE_DIR)
   endif(CLAPACK_INCLUDE_DIR)
 
-  find_library(CLAPACK_LIBRARY clapack)
+  find_library(CLAPACK_LIBRARY clapack PATH_SUFFIXES atlas)
   if(CLAPACK_LIBRARY)
       message(STATUS "Found clapack library: ${CLAPACK_LIBRARY}")
   endif(CLAPACK_LIBRARY)
diff -ur digikam-2.1.1/core/libs/dimg/filters/sharp/matrix.cpp digikam-2.1.1-clapack-atlas/core/libs/dimg/filters/sharp/matrix.cpp
--- digikam-2.1.1/core/libs/dimg/filters/sharp/matrix.cpp	2011-09-14 08:22:03.000000000 +0200
+++ digikam-2.1.1-clapack-atlas/core/libs/dimg/filters/sharp/matrix.cpp	2011-09-23 10:19:09.000000000 +0200
@@ -36,7 +36,6 @@
 
 extern "C"
 {
-#include "f2c.h"
 #include "clapack.h"
 }
 
@@ -653,14 +653,12 @@
 
 int RefocusMatrix::dgesv(const int N, const int NRHS, double* A, const int lda, double* B, const int ldb)
 {
-    int result = 0;
-    integer i_N = N, i_NHRS = NRHS, i_lda = lda, i_ldb = ldb, info;
-    QScopedArrayPointer<integer> ipiv(new integer[N]);
+    int result;
+    QScopedArrayPointer<int> ipiv(new int[N]);
 
     // Clapack call.
-    dgesv_(&i_N, &i_NHRS, A, &i_lda, ipiv.data(), B, &i_ldb, &info);
+    result = clapack_dgesv (CblasColMajor, N, NRHS, A, lda, ipiv.data(), B, ldb);
 
-    result = info;
     return (result);
 }
 


Reproducible: Always

Actual Results:  
  

Expected Results:
Comment 1 nucleo 2012-03-06 16:23:39 UTC
Created attachment 69328 [details]
patch fixes build against external libclapack

With this pacth digikam builds against external libclapack but in Help - Components still shown that it is internal (the same with external libpgf).
Comment 2 Rex Dieter 2012-03-06 16:26:53 UTC
This is just a firs try to use atlas instead, and is probably not usable directly as is.  But if something like this is agreeable in principle, we could work to add conditionals to support both lapack and atlas.

(and in a perfect world, move torward using something like eigen instead, but that's even more work... :) )
Comment 3 Kevin Kofler 2012-03-06 16:28:29 UTC
I don't think this patch can be merged as is, without adding some conditional to support both vanilla clapack and ATLAS's version of clapack which is not quite the same thing. (We're using ATLAS's version in Fedora, we don't have a system package of vanilla clapack.)

And what about porting the code to use Eigen instead? It's the preferred solution for linear algebra in the KDE world and it can do this simple operation (dgesv is just solving a linear system of equations by straightforward LU decomposition).
Comment 4 Marcel Wiesweg 2012-03-06 18:22:14 UTC
any patch is welcome ;-)
Comment 5 caulier.gilles 2012-03-06 20:04:36 UTC
To all,

Please look patch attached to this file about eigen support :

https://bugs.kde.org/show_bug.cgi?id=251563

Gilles Caulier
Comment 6 caulier.gilles 2013-02-24 08:39:02 UTC
I would like to remove internal clapack from digiKam core.

If i understand all the way, we have two possibilities :

1/ Using Atlas shared library (see patch from this file).
2/ Using Eigen shared library (see patch from bug #251563).

For both solution, only relevant plugin must be not compiled. Only Refocus tool from editor and BQM use it - see Sharpen plugin. This dependency must be optional. I don't see this behavior in patches.

Also, what's the best solution : Atlas or Eigen ? As Francesco said in the past, Eigen has a lots of supplementary dependencies.

Gilles Caulier
Comment 7 Thomas Capricelli 2013-02-24 20:13:08 UTC
Hello.
I'm the author of the "eigen" patch, and also a developer on eigen.

Just to fix a few points : 

1) i don't know who francesco is and where he made the statement about dep, but it's false. Citing our homepage http://eigen.tuxfamily.org
"Eigen doesn't have any dependencies other than the C++ standard library."

2) it seems there's a misunderstanding about eigen. Eigen is based on templates, and as such is NOT a library. It's not something you linke statically or dynamically. You only need to have eigen include files at compile time, and this will generate only the needed code for your application.

3) i dont remember about my patch (it was submitted very long ago and not accepted as is if i remember well), but it's probably true that it didn't include the relevant part to make eigen support optional. But this is probably very easy to do, and more easily done by someone used to digikam code (and its build system).

4) You seem to be very "cold"/"shy" with using eigen , not to say frightened. Eigen has its roots in KDE (was started and hosted here), and, more importantly, eigen is way, way, better than any such library. I can say it , i'm not an initial author. Whatever your criteria are  (fiability, speed, dependencies, hope of being maintained in 10 years, efficiency, beauty of code, beauty of API, friendliness of authors, and even closeness to KDE). I did choose eigen long ago after having made a HUGE comparisons of all existing stuff, and it was not only the best, but beating all others with a very large margin. You can't make a bad choice going for them.  I know the KDE team just love making plugins and allowing different backends and such. But here, it's just useless and a waste of time, imho.
Comment 8 caulier.gilles 2013-02-24 21:14:16 UTC
1/  ==> Lok this comment : https://bugs.kde.org/show_bug.cgi?id=251563#c13
Comment 9 Rex Dieter 2013-02-24 21:22:18 UTC
All things being equal feature-wise, eigen is definitely the way to go (imho)
Comment 10 caulier.gilles 2013-02-24 21:47:02 UTC
Rex,

If i understand well comment #7 from Thomas, Eigen is already used by KDE core ? If yes, where exactly ? For which components, and which features ?

Gilles Caulier
Comment 11 Rex Dieter 2013-02-24 21:58:04 UTC
kdeplasma-addons(wallpapers/mandelbrot), kdeartwork(krotation,kpendulum screenssavers) core modules use eigen2

Mind you, it's a build-time dependency only, so nice that it adds nothing at runtime.
Comment 12 caulier.gilles 2013-02-24 22:01:35 UTC
Thanks Rex,

So, Eigen is the right way to go...

Gilles
Comment 13 Thomas Capricelli 2013-02-24 22:55:47 UTC
(In reply to comment #8)
> 1/  ==> Lok this comment : https://bugs.kde.org/show_bug.cgi?id=251563#c13

Oh, this one is not about eigen having big dependencies. But the fact that some modules in KDE still use eigen2 while the current version of eigen is 3. This is no great deal.

Actually, we (the eigen team) have access to KDE code and we planned to port those to eigen3, but we kinda failed to find the time to do so.
Though i'm pretty sure there's no much work to do, if ever. Eigen 2 and 3 API are very similar, and eigen 3 is more about adding new features. Sure, few API's were obsolated, but not much iirc.
Comment 14 Thomas Capricelli 2013-02-24 23:03:41 UTC
Just to clarify. Francesco was saying that it was better to stay with eigen2, and my patch on this other bug is against eigen2. So everything seems... just fine. isn't it ?
Comment 15 Kevin Kofler 2013-02-25 00:37:32 UTC
As the author of the patch which started this thread, I'd also go with Eigen (in fact, I wrote https://bugs.kde.org/show_bug.cgi?id=251563#c11 a year ago, but didn't get around to updating the Fedora package to pick up the changed patch). I did the minimum change to get rid of the bundled library, but observed right when I wrote it that it needs only one LAPACK function, so it'd be fairly easy to use something different. Eigen seems a better fit for KDE than clapack, and it also avoids the ugly compatibility issues between different clapack implementations (reference clapack vs. ATLAS).

As for what version, I'd say the latest version (Eigen 3) would be the better choice, it's not so nice to be stuck on an old version.
Comment 16 Francesco Riosa 2013-02-25 11:52:14 UTC
(In reply to comment #6)
> I would like to remove internal clapack from digiKam core.
> 
> If i understand all the way, we have two possibilities :
> 
> 1/ Using Atlas shared library (see patch from this file).
> 2/ Using Eigen shared library (see patch from bug #251563).
> 
> For both solution, only relevant plugin must be not compiled. Only Refocus
> tool from editor and BQM use it - see Sharpen plugin. This dependency must
> be optional. I don't see this behavior in patches.
> 
> Also, what's the best solution : Atlas or Eigen ? As Francesco said in the
> past, Eigen has a lots of supplementary dependencies.
> 
> Gilles Caulier

Gilles, is the other way around those are the packages that already DEPEND ON eigen, it was supportive.
Sorry again for my sucking english :-(

The only problem I could see at the time is that eigen2 was used by most application and the upgrade to eigen3 was slow.  Hopefully this has been solved by now.

Cheers
Comment 17 caulier.gilles 2013-02-26 09:03:38 UTC
Another question :

Currently, Atlas library is checked to find a external clapack implementation from host computer. If nothing is found, internal implementation from digiKam core is used instead.

If internal implementation is removed, and Eigen check added, Do you think that both Eigen and Atlas checks must still used, or only Eigen (optional Altlas dependency removed in this case) ?

Gilles Caulier
Comment 18 Thomas Capricelli 2013-02-26 12:17:22 UTC
My point of view is that you should only use/depend on eigen. Remember it's a compile-time only dependancy. That would mean
* remove the internal lapack copy
* remove the external lapack library check and related logic
* the eigen check is included in my patch
Comment 19 Kevin Kofler 2013-02-26 16:34:50 UTC
I'd say the same, just Eigen should be enough.
Comment 20 Kevin Kofler 2013-02-26 16:36:05 UTC
And by the way, I'd personally not bother making it optional. In fact, as a distro packager, I don't like optional dependencies at all, I want my build to fail hard if I'm missing a BuildRequires, not silently build a crippled package.
Comment 21 Kevin Kofler 2013-02-26 16:38:36 UTC
PS (and sorry for the 3 posts in sequence): (and for us, even printing a warning to stdout or stderr at build time is still "silent", we rarely look at build logs for successful builds)
Comment 22 Francesco Riosa 2013-02-26 17:19:48 UTC
(In reply to comment #20)
> And by the way, I'd personally not bother making it optional. In fact, as a
> distro packager, I don't like optional dependencies at all, I want my build
> to fail hard if I'm missing a BuildRequires, not silently build a crippled
> package.

Kevin what you want is a package that fail hard if a *requested* option miss a dependancy.
If for whatever reason someone don't need that function it could still be a good thing being able to remove it. However if unwanted the function (and dep.) should NOT magically being added 

That said in this case depend unconditionally upon eigen seem a good thing since it already work on all digikam supported platforms, it's a build time dependancy and what use it is almost universally useful.

just 2c
Comment 23 Kevin Kofler 2013-02-26 17:32:56 UTC
> Kevin what you want is a package that fail hard if a *requested* option miss a dependancy.

Unfortunately, that's not good enough (and it's a common mistake made by developers, and in fact the whole optional dependency system in KDE gets that wrong). The package should fail hard if I did NOT explicitly request that I DON'T want the dependency. Everything not explicitly disabled should be required. Otherwise, when you add some new functionality, it is still likely to be missing in packages, because if we don't know to add the BuildRequires, we also won't know about the -D switch to add to explicitly request the feature. Opt-in requesting is entirely useless for packaging, we already opt in by adding a BuildRequires to our packages, it needs to be opt-out!

I think we should probably have some "packager mode" in CMake (a -D flag we could add to our %cmake RPM macro) where all the optional dependencies are required unless explicitly disabled. But this is getting way out of the scope of this bug. ;-)
Comment 24 Francesco Riosa 2013-02-26 17:40:04 UTC
(In reply to comment #23)
Fair enough, only thing yet uncovered are mutually exclusive options.