FS#15208 - [octave] 3.0.5-2 don't depends anymore with liblapack

Attached to Project: Arch Linux
Opened by Gerardo Exequiel Pozzi (djgera) - Monday, 22 June 2009, 02:33 GMT
Last edited by Ronald van Haren (pressh) - Monday, 22 June 2009, 10:02 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Ronald van Haren (pressh)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Seems that because octave not list as depends the lapack  FS#14475  and Allan do the rebuild inside a chroot, octave don't have dependency in lapack, that in this case is really used be octave.

For example the function "zgeesx" commonly found in lapack:

$ readelf -s /usr/lib/octave-3.0.5/liboctave.so.3.0.5 | grep zgeesx # octave-3.0.5-1
366: 00000000 0 FUNC GLOBAL DEFAULT UND zgeesx_

$ readelf -s /usr/lib/liblapack.so.3 | grep zgeesx # lapack-3.2-2
814: 002ff8f0 2942 FUNC GLOBAL DEFAULT 11 zgeesx_

$ readelf -s /usr/lib/octave-3.0.5/libcruft.so.3.0.5 | grep zgeesx # octave-3.0.5-2
$

Shows that "zgeesx" defined in liblapack.

But now is defined at libcruft.

$ readelf -s /usr/lib/octave-3.0.5/libcruft.so.3.0.5 | grep zgeesx # octave-3.0.5-2
566: 000ae7f0 2768 FUNC GLOBAL DEFAULT 11 zgeesx_


Anyway no unresolved symbols are in libraries, but...I am not sure, maybe not all funcions are satifaced in libcruft (lapack have hundred of functions, and I only checked one), and now octave lacks some functionality.
This task depends upon

Closed by  Ronald van Haren (pressh)
Monday, 22 June 2009, 10:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.0.5-3 is build against lapack
Comment by Allan McRae (Allan) - Monday, 22 June 2009, 03:56 GMT
Oops...

@Ronald: I can push the rebuild in ~24 hours if you have not gotten to this by then.
Comment by Ronald van Haren (pressh) - Monday, 22 June 2009, 03:56 GMT
in that case I don't understand what happened I normally always build my packages in a clean chroot for quite some time...

ah well, do you say some functions don't exist anymore or that you don't know if all functions exist? because in the second case we should just wait til somebody complains something is not working?
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 22 June 2009, 04:32 GMT
Maybe you have a clean chroot but with lapack inside ? Otherwise octave can not be linked with lapack.

I do not know if _all_ functions provided in lapack are in libcruft from octave. In octave home page in build instructions list both BLAS and LAPACK as deps.

Seems that build system detect if blas, lapack and fft are installed, and if not build internal files in libcruft.

CRUFT_DIRS = amos @BLAS_DIR@ blas-xtra daspk dasrt dassl \
@FFT_DIR@ @LAPACK_DIR@ lapack-xtra minpack \
misc odepack ordered-qz quadpack ranlib \
slatec-err slatec-fn villad
...
DISTSUBDIRS = $(sort $(CRUFT_DIRS) blas fftpack lapack)
...

PS: I just trigger this bug report, because I was do a comparision for all recently rebuilded pkgs, viewing what libraries links was changed.
Comment by Allan McRae (Allan) - Monday, 22 June 2009, 04:51 GMT
From this it seems nothing will actually be broken (as libcruft fills in for lapack etc), but lapack will be faster so there will a performance loss. I say adding lapack as a dep and rebuilding is the way to go.
Comment by Ronald van Haren (pressh) - Monday, 22 June 2009, 10:02 GMT
@Gerardo: yeah seems to be the logical explanation. I've recreated my chroots many times since then so it should be fine now.

@Allan, thanks for the explanation, rebuild against lapack in 3.0.5-3 in testing now.

Loading...