bugGNU Octave - Bugs: bug #49547, Update libs blas and lapack

 
 

bug #49547: Update libs blas and lapack

Submitter:  Ll <pipeng>
Submitted:  Sun 06 Nov 2016 05:24:24 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 10 Nov 2016 02:24:46 AM UTC, comment #14: 

Right, but we don't see this problem on other distros because on other distros users just install whatever ATLAS/BLAS/OpenBLAS libraries are provided by the vendor, and this problem hasn't come up very much in the time I've been triaging bugs and helping people get Octave working. Except for these two bug reports, both on Gentoo systems.

But if you don't think there's anything particular about Gentoo worth documenting, that's fine too. This bug is closed.

Mike Miller <mtmiller>
Group Member
Wed 09 Nov 2016 08:01:46 PM UTC, comment #13: 

The problem isn't specific to gentoo, but it isn't a bug in Octave either.  It's just the way that shared libraries work with versioning info.  By default, Octave (really, it's configure script) doesn't search for libblas.so.3.  It justs searches for and links with -lblas.  But when the link step happens, it is linked with a specific version.  The version is allowed to change, provided that the new version is compatible with the old.  If not, then the dynamic linker will reject the new library and you won't be able to run Octave unless you install an appropriate version or rebuild/relink Octave so that it uses the newer library.

John W. Eaton <jwe>
Group administrator
Wed 09 Nov 2016 07:04:54 PM UTC, comment #12: 

Okis, well i post the info here because i think this don't is a specific gentoo problem, in gentoo get can get an easy fix for all of this because we can handle it manually, the problem start with other distros, where the user can't so this.

Thx. Cya.

Ll <pipeng>
Wed 09 Nov 2016 06:51:32 PM UTC, comment #11: 

If there is some information or advice you could add to help other Gentoo users avoid these kinds of problems, think about creating a wiki page for building and configuring Octave on Gentoo.

Mike Miller <mtmiller>
Group Member
Wed 09 Nov 2016 06:30:36 PM UTC, comment #10: 

Hi!, Thx!, now i think we can be sure, don't is a octave problem, basically when the system has broken libs it goes crazy.

I think this issue have enough info for the record and future issues, so if you are agree i think this is solved.

Cya.

Ll <pipeng>
Wed 09 Nov 2016 06:21:44 PM UTC, comment #9: 

The path to shared libraries is determined by the system and by the -L options passed to Octave when it is compiled. The default paths are determined by the system ld.so.conf (check ldconfig -p), the environment variable LD_LIBRARY_PATH, and a program or shared library can have additional paths compiled into it (check objdump -p filename | grep RPATH).

Mike Miller <mtmiller>
Group Member
Wed 09 Nov 2016 02:29:46 AM UTC, comment #8: 

Hi, i can't say now if is something it need a fix, first we need check if is a octave problem, but before, i post all of this because i found a lot of this problems in the web not only in gentoo, so with this we can avoid or have a way to fix or at least be sure what type of problem is, because i think is a bad idea finish the issue without a solution like the other bug report.

And now the question, How octave get the path of the libs?
If get it with different ways, how octave get the paths for BLAS and LAPACK?

Thx. Cya.

Ll <pipeng>
Tue 08 Nov 2016 10:39:10 PM UTC, comment #7: 

Do you think any of these problems are Octave build system problems?

I still don't understand fully, but I suspect this is all a gentoo packaging configuration issue that can be resolved with the right set of codependent packages installed.

Is there anything you think Octave needs to do differently? I haven't seen it yet.

Mike Miller <mtmiller>
Group Member
Tue 08 Nov 2016 08:33:50 PM UTC, comment #6: 

Hi, Thx for your help, reading and experimenting i found some things, and the solution, first is a system problem, but has 2 problems:

1) Some libs don't was rebuilt with LAPACK and BLAS changed versions.

2) Octave use BLAS and LAPACK directly, but when exist the above problem we get an error, basically can't found the actual libs, its like is trying to search the libs in the broken depends paths.

So with this in mind to solve this at least in gentoo we can use:

revdep-rebuild


For the systems do not build their own libs is necessary send a bug report to rebuild the libs.

I think part of this is done, i would like check the second point, of how octave get libs path to finish this.

Mike do you know how octave does this?


Only as a note, in the bug https://savannah.gnu.org/bugs/?42760
they said octave wasn't using BLAS and LAPACK directly, but i confirm is using it, so testing and searching direct dependencies of libs this files of octave use it:


/usr/lib64/octave/4.3.0+/liboctave.so
/usr/lib64/octave/4.3.0+/liboctave.so.4
/usr/lib64/octave/4.3.0+/liboctave.so.4.0.0
/usr/lib64/octave/4.3.0+/liboctgui.so
/usr/lib64/octave/4.3.0+/liboctgui.so.2
/usr/lib64/octave/4.3.0+/liboctgui.so.2.0.0
/usr/lib64/octave/4.3.0+/liboctinterp.so
/usr/lib64/octave/4.3.0+/liboctinterp.so.4
/usr/lib64/octave/4.3.0+/liboctinterp.so.4.0.0
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__delaunayn__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__eigs__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__fltk_uigetfile__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__glpk__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__init_fltk__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__init_gnuplot__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__osmesa_print__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/__voronoi__.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/amd.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/audiodevinfo.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/audioread.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/ccolamd.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/chol.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/colamd.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/convhulln.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/dmperm.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/fftw.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/gzip.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/qr.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/symbfact.oct
/usr/lib64/octave/4.3.0+/oct/x86_64-pc-linux-gnu/symrcm.oct


We can found direct dependencies with objdump -x if you try ldd you will get a recursion dependence.


If you need found the broken libs you can follow this:
first search broken libs
In cli

ldd -v /usr/bin/octave

for gui

ldd -v /usr/libexec/octave/4.3.0+/exec/x86_64-pc-linux-gnu/octave-gui


in the log you will can see something like "not found" with broken libs, and it will say what libs depends of it, so then you need search what package files belongs and send the bug report.

Thx. Cya.

Ll <pipeng>
Tue 08 Nov 2016 06:42:37 AM UTC, comment #5: 

See also bug #42760 that was previously reported and closed without a resolution, it sounds like that user may have had a similar configuration as you.

Mike Miller <mtmiller>
Group Member
Tue 08 Nov 2016 06:31:30 AM UTC, comment #4: 

The names of the BLAS and LAPACK libraries are discovered by Octave when it is built, there is no searching done at run time.

This sounds like a local configuration problem. I am almost certain that if you install the correct BLAS and LAPACK or OpenBLAS libraries, and possibly rebuild Octave, then everything will work correctly.

Did you build Octave from source against a different version of these libraries than is now installed? On my Debian system, Octave is configured and built against libblas.so.3 and liblapack.so.3, and those libraries are loaded at runtime.

I don't know why your built Octave is looking for libblas.so.0 and liblapack.so.0, were these provided by some other package or library that was removed or moved out of the way since building Octave?

Mike Miller <mtmiller>
Group Member
Mon 07 Nov 2016 10:24:05 PM UTC, comment #3: 

Note, execution and build actually fails.

Ll <pipeng>
Mon 07 Nov 2016 09:54:16 PM UTC, comment #2: 

Hi! thx for your answer, and yes, i'm using Gentoo 64, if you need info about it ask, and i don't know i'll try research it.

This is basically don't update the code about how octave use BLAS and LAPACK, is the name of the libs, i print here the default config of gentoo system, so:

Octave needs libblas.so.0 and liblapack.so.0

The new versions of BLAS and LAPACK don't install this files, instead there is libblas.so.3 and liblapack.so.3

So, Gentoo should install or link the files? or octave need update the files?

Thx. Cya.

Ll <pipeng>
Mon 07 Nov 2016 07:06:29 PM UTC, comment #1: 

I'm sorry, but I don't know what you think Octave or Octave's configure script should be doing differently in your report.

The only thing that Octave needs for BLAS and LAPACK functions are one or two libraries that have the expected functions, they can exist anywhere on the user's system and can be configured with either the standard LIBS and LDFLAGS variables, or with the --with-blas and --with-lapack functions.

Do you think that there is a specific OS or distribution that installs BLAS or OpenBLAS in a default location that Octave does not find by default? I'm guessing that these examples you are showing are from gentoo, but I don't know anything about gentoo or whether what you're showing is a default configuration or not.

Mike Miller <mtmiller>
Group Member
Sun 06 Nov 2016 05:24:24 PM UTC, original submission:  

Hi all, i think octave need update the search paths and files for this libs, if the system should have other sym links please tell me and i'll send other bug issue to the right please, i check some systems and the files in this two libs are common saved like this:


pipe@Hi /usr/lib64 $ equery f blas-reference lapack-reference
 * Searching for blas-reference ...
 * Contents of sci-libs/blas-reference-20151113-r1:
/etc
/etc/env.d
/etc/env.d/blas
/etc/env.d/blas/lib64
/etc/env.d/blas/lib64/reference
/usr
/usr/lib64
/usr/lib64/blas
/usr/lib64/blas/reference
/usr/lib64/blas/reference/blas.pc
/usr/lib64/blas/reference/libblas.so -> libblas.so.3
/usr/lib64/blas/reference/libblas.so.3 -> libblas.so.3.6.0
/usr/lib64/blas/reference/libblas.so.3.6.0
/usr/share
/usr/share/doc
/usr/share/doc/blas-reference-20151113-r1
/usr/share/doc/blas-reference-20151113-r1/README.bz2

 * Searching for lapack-reference ...
 * Contents of sci-libs/lapack-reference-3.6.0:
/etc
/etc/env.d
/etc/env.d/lapack
/etc/env.d/lapack/lib64
/etc/env.d/lapack/lib64/reference
/usr
/usr/lib64
/usr/lib64/cmake
/usr/lib64/cmake/lapack-3.6.0
/usr/lib64/cmake/lapack-3.6.0/lapack-config-version.cmake
/usr/lib64/cmake/lapack-3.6.0/lapack-config.cmake
/usr/lib64/cmake/lapack-3.6.0/lapack-targets-gentoo.cmake
/usr/lib64/cmake/lapack-3.6.0/lapack-targets.cmake
/usr/lib64/lapack
/usr/lib64/lapack/reference
/usr/lib64/lapack/reference/lapack.pc
/usr/lib64/lapack/reference/liblapack.so -> liblapack.so.3
/usr/lib64/lapack/reference/liblapack.so.3 -> liblapack.so.3.6.0
/usr/lib64/lapack/reference/liblapack.so.3.6.0
/usr/share
/usr/share/doc
/usr/share/doc/lapack-reference-3.6.0
/usr/share/doc/lapack-reference-3.6.0/README.bz2


As you can see now don't exist liblapack.so.0 and libblas.so.0, instead we have liblapack.so.3 and libblas.so.3

So with this we can't build or run octave...


octave --no-gui
/usr/libexec/octave/4.3.0+/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libblas.so.0: cannot open shared object file: No such file or directory



/var/tmp/portage/sci-mathematics/octave-9999/work/octave-9999/src/.libs/octave-cli/var/tmp/portage/sci-mathematics/octave-9999/work/octave-9999/src/.libs/octave-cli/var/tmp/portage/sci-mathematics/octave-9999/work/octave-9999/src/.libs/octave-cli: /var/tmp/portage/sci-mathematics/octave-9999/work/octave-9999/src/.libs/octave-cli/var/tmp/portage/sci-mathematics/octave-9999/work/octave-9999/src/.libs/octave-cli: : error while loading shared libraries: : error while loading shared librarieserror while loading shared libraries: error while loading shared librarieserror while loading shared libraries: : libblas.so.0: : libblas.so.0libblas.so.0: libblas.so.0libblas.so.0: : cannot open shared object file: : cannot open shared object filecannot open shared object file: cannot open shared object filecannot open shared object file: : No such file or directory: : No such file or directoryNo such file or directory
No such file or directoryNo such file or directory


Thx. Cya.

Ll <pipeng>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by pipeng (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-09 mtmiller Open/ClosedOpen Closed
    2016-11-08 mtmiller Dependencies- Depends on bugs #42760
    2016-11-07 mtmiller CategoryLibraries Configuration and Build System
        StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code