bugGNU Octave - Bugs: bug #57935, mkoctfile: unrecognized argument...


bug #57935: mkoctfile: unrecognized argument /path/to/libopenblas.so

Submitted by:  ederag <ederag>
Submitted on:  Sun 01 Mar 2020 07:09:29 PM UTC  
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  3 - Low Item Group:  Unexpected Error
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  5.2.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Thu 12 Mar 2020 04:17:22 PM UTC, comment #5: 

Octave is still great, very robust,
one of the best scientific computing systems out there,
but seems to focus more and more on compatibility with matlab
and on basic users.
(fully understandable, that's the main target)

Indeed with '--with-blas=openblas' it works fine,
but it is less explicit.
You have to make sure the correct directory happens first in the LDFLAGS.
(use case: try a new non-installed blas).

No big deal. It just used to work in octave-4.4.1

Thanks for the answers, and for your work !

ederag <ederag>
Mon 02 Mar 2020 10:55:55 PM UTC, comment #4: 

I'll take a couple minutes to respond on your other patch items if you are looking for a response there. I'm sorry if you have felt discouraged about contributing to or continuing to use Octave, but if it's not for you, that's fine, many of us also use and find immense value in Python and Julia and other projects as well.

Mike Miller <mtmiller>
Project Administrator
Mon 02 Mar 2020 10:51:49 PM UTC, comment #3: 

Sorry, not the option, the unusual part is linking with a .so file by its full file name.

I would normally build Octave with '--with-blas=blas' or '--with-blas=openblas', and then if you have to, include the directory in LDFLAGS, e.g. 'LDFLAGS=-L/usr/local/gcc-9.2.0_binutils-2.32_isl/lib64'. And maybe also include a '-Wl,-rpath' option as well, if that directory isn't already in your dynamic linker search path.

In fact, if you include that -L option in LDFLAGS, configure should automatically find libopenblas and use it as the BLAS / LAPACK library without any '--with-blas' option needed.

Mike Miller <mtmiller>
Project Administrator
Mon 02 Mar 2020 08:46:14 PM UTC, comment #2: 

Thanks for the answer.

Unusual but documented:

../configure --help | grep -i blas
  --with-blas=<lib>       use BLAS library <lib>


I would highly appreciate to see what you'd call the usual way;
that would settle it since recompiling octave is easy.

When I try without this option, I just get

> configure: error: BLAS and LAPACK libraries are required

does exists and contain both the blas and the lapacklibs, as usual.

About motivation to provide a patch, I already have 3 pending
Not blaming anyone, mind you, being maintainer is tough,
but this list will hopefully show that there was no lack of good will.

ederag <ederag>
Mon 02 Mar 2020 06:13:17 PM UTC, comment #1: 

Yeah, confirmed here. This is a very unusual way to link with a shared library, which is probably why this has never been noticed before. Easily worked around by building differently, and probably also easy to fix if someone is motivated to submit a patch for this.

Mike Miller <mtmiller>
Project Administrator
Sun 01 Mar 2020 07:09:29 PM UTC, original submission:  

mkoctfile seems to fail when blas libraries are given as a path to the '.so' file.

Installing nan yields

pkg install -forge nan
mkoctfile: unrecognized argument /usr/local/gcc-9.2.0_binutils-2.32_isl/lib64/libopenblas.so
/usr/local/gcc-9.2.0_binutils-2.32_isl/bin/mkoctfile-5.2.0 --mex -lgomp /usr/local/gcc-9.2.0_binutils-2.32_isl/lib64/libopenblas.so train.c tron.o linear.o linear_model_matlab.c

ans =  '--with-blas=/usr/local/gcc-9.2.0_binutils-2.32_isl/lib64/libopenblas.so' 'CPPFLAGS=-I/usr/local/gcc-9.2.0_binutils-2.32_isl/include:/usr/include' 'CFLAGS=-O2 -march=native' 'CXXFLAGS=-O2 -march=native' 'FFLAGS=-O2 -march=native' 'LDFLAGS=-L/usr/local/gcc-9.2.0_binutils-2.32_isl/lib64 -Wl,-rpath,/usr/local/gcc-9.2.0_binutils-2.32_isl/lib64' 'PKG_CONFIG_PATH=/usr/local/gcc-9.2.0_binutils-2.32_isl/lib64/pkgconfig' 'JAVA_HOME=/usr/lib64/jvm/java-10-openjdk-10' '--prefix=/usr/local/gcc-9.2.0_binutils-2.32_isl'

Very similar error for optim, so it is not related to the --mex option at all.
The nan package is a good example because it has been reported to work with 5.2.0: bug #57263

From the following comment, at least the argument is at its expected place.

ederag <ederag>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ederag (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-03-02 mtmiller Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
        Item GroupBuild Failure => Unexpected Error
        StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5