Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 206934 - <=media-gfx/digikam-1.2.0 has internal copy of CLAPACK
Summary: <=media-gfx/digikam-1.2.0 has internal copy of CLAPACK
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
Whiteboard: [kde testing]
Keywords: InOverlay
Depends on: 302951 309675
Blocks: bundled-libs
  Show dependency tree
Reported: 2008-01-21 21:33 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2010-10-12 18:03 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---
tampakrap: Bugday?

Patch to switch from internal clapack copy to system lapack (digikam-1.1.0-lapack.patch,6.16 KB, patch)
2010-02-14 22:48 UTC, Andreas K. Hüttel
Details | Diff
Updated ebuild (new dependencies on virtual/lapack and sys-devel/gcc[fortran]) (digikam-1.1.0-r1.ebuild,2.04 KB, text/plain)
2010-02-14 22:49 UTC, Andreas K. Hüttel

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2008-01-21 21:33:43 UTC
As per summary, feel free to verify...
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2009-10-15 12:34:20 UTC
Still a problem for KDE4 version of digikam, 0.10.0.
Comment 2 Ronan Arraes Jardim Chagas 2010-02-04 22:00:23 UTC
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.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2010-02-05 18:00:43 UTC
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
Comment 4 Andreas K. Hüttel gentoo-dev 2010-02-14 22:48:27 UTC
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... :)
Comment 5 Andreas K. Hüttel gentoo-dev 2010-02-14 22:49:44 UTC
Created attachment 219725 [details]
Updated ebuild (new dependencies on virtual/lapack and sys-devel/gcc[fortran])
Comment 6 Andreas K. Hüttel gentoo-dev 2010-03-03 23:51:03 UTC
Anyone from sci interested in adding clapack to the main tree? (Is in overlay...)
Comment 7 Justin Lecher (RETIRED) gentoo-dev 2010-03-04 10:09:36 UTC
I dropped clapack into the tree. please test if it works.
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2010-03-04 11:07:06 UTC
(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])

Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2010-03-04 11:08:51 UTC
Futhermore, clapack doesn't provide a shared lib at all!
Comment 10 Andreas K. Hüttel gentoo-dev 2010-03-04 11:47:44 UTC
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.
Comment 11 Justin Lecher (RETIRED) gentoo-dev 2010-03-04 11:50:30 UTC
So is clapack included in the lapack-reference?
Comment 12 Justin Lecher (RETIRED) gentoo-dev 2010-03-04 11:57:27 UTC
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.
Comment 13 Andreas K. Hüttel gentoo-dev 2010-03-04 12:08:43 UTC

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.
Comment 14 Justin Lecher (RETIRED) gentoo-dev 2010-03-04 12:19:23 UTC
Against which *lapack libs exactly links the current ebuild?
Comment 15 Andreas K. Hüttel gentoo-dev 2010-03-17 21:51:21 UTC
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,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, /usr/lib64/ 
ET_DYN,,,,,,,,,,,,,,,,,,,,, /usr/lib64/ 
huettel@pinacolada ~ $ 

Comment 16 Andreas K. Hüttel gentoo-dev 2010-05-30 20:19:07 UTC
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...
Comment 17 Maciej Mrozowski gentoo-dev 2010-07-09 23:32:57 UTC
Now in tree. Thanks to all involved!