[Bug 295423] New: External libclapack not used

[nucleo]

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

            Bug ID: 295423
          Severity: normal
           Version: unspecified
          Priority: NOR
          Assignee: [hidden email]
           Summary: External libclapack not used
    Classification: Unclassified
                OS: Linux
          Reporter: [hidden email]
          Hardware: Other
            Status: UNCONFIRMED
         Component: general
           Product: digikam

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:

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[nucleo]

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

--- Comment #1 from nucleo <[hidden email]> ---
Created attachment 69328
  --> https://bugs.kde.org/attachment.cgi?id=69328&action=edit
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).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Rex Dieter]

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

Rex Dieter <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Rex Dieter <[hidden email]> ---
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... :) )

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Kevin Kofler]

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

Kevin Kofler <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #3 from Kevin Kofler <[hidden email]> ---
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).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #4 from Marcel Wiesweg <[hidden email]> ---
any patch is welcome ;-)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from Gilles Caulier <[hidden email]> ---
To all,

Please look patch attached to this file about eigen support :

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

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Portability
            Summary|External libclapack not     |External libclapack not
                   |used                        |used [patch]

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

--- Comment #6 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Thomas Capricelli]

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

Thomas Capricelli <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #7 from Thomas Capricelli <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

--- Comment #8 from Gilles Caulier <[hidden email]> ---
1/  ==> Lok this comment : https://bugs.kde.org/show_bug.cgi?id=251563#c13

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Rex Dieter]

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

--- Comment #9 from Rex Dieter <[hidden email]> ---
All things being equal feature-wise, eigen is definitely the way to go (imho)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

--- Comment #10 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Rex Dieter]

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

--- Comment #11 from Rex Dieter <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

--- Comment #12 from Gilles Caulier <[hidden email]> ---
Thanks Rex,

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

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Thomas Capricelli]

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

--- Comment #13 from Thomas Capricelli <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Thomas Capricelli]

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

--- Comment #14 from Thomas Capricelli <[hidden email]> ---
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 ?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Kevin Kofler]

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

--- Comment #15 from Kevin Kofler <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Francesco Riosa-2]

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

Francesco Riosa <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #16 from Francesco Riosa <[hidden email]> ---
(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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

--- Comment #17 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Thomas Capricelli]

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

--- Comment #18 from Thomas Capricelli <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel