When I compile OpenBLAS with NOFORTRAN=1 some LAPACK (e.g. dpotrf) routines are not available

[burlachenkok]

Hi,
I'd like to build complete version of openBlas with maximum support of lapack/blas routines without using gfortran in runtime.

When I'm building openBlas from:
develop branch from commit 50715e8
with specifying NOFORTRAN=1 in make command

In this circumstances I don't have several routines in the final static library. They are:

1. dpotrf
2. dpotrs
3. dgels
4. dpotrf
5. zpotrf
6. dlarfg
7. dlarf
8. zlarfg
9. zlarf
10. dlarft
11. zlarft
12. zlarfb
13. dlarfb
14. dlarft

What is interesting this all symbols are defined if build withtout NOFORTRAN=1.
Unfortunately I want to have OpenBlas library without dependencies in gfortran

[martin-frbg]

Most of the LAPACK functions in OpenBLAS are verbatim copies of the netlib reference implementation which happens to be written in FORTRAN, there is only a select few (in interface/lapack) that get replaced by C functions. (While these happen to include the portf functions, dgels and at least some of the larf variants are not reimplemented). So a NOFORTRAN=1 build will
lack all LAPACK modules (unless perhaps you did a full build first and omitted the "make clean" so there were some object files still around from the first run). Perhaps statically linking against libgfortran (and its dependency libquadmath) would be acceptable for your project ?

[burlachenkok]

Thanks, for fast answer.

My project is dynamic library with fPIC code.
I tried to link with libgfortran.a from gcc-4.7,4.8,4.9 - but static libraries from GNU GCC which I have in my dev ubuntu x86_64 machine consist of some object files with fPIC code, some not.

So I rebuid libgfortran and libquadmath (which are parts of gcc) from sources with forcing extra fPIC flag.
But during linkage with libgfortran.a I received also some problems in specific version of gnu ld (2.24), which I should use. There is no problem in ld 2.26

Looks that this ld version 2.24(which have been released in ~2013 http://ftp.gnu.org/gnu/binutils/) is buggy. Version 2.25 is also buggy and has various patches during 2014-2015.

During linkage of final shared library I received the similar problem to this issue:
golang/go#13678

[burlachenkok]

Does it exist plans to implement this functions in future?

[martin-frbg]

Not to my knowledge. The closest effort is probably ReLAPACK (which got added recently), but it reimplements only those functions for which a recursive algorithm seemed appropriate and still makes calls to regular LAPACK functions.
If you are really desperate for a FORTRAN-free solution you could try converting all LAPACK files with f2c (though that would induce a dependency on libf2c), probably quite messy.

[brada4]

In Ubuntu you need matching gcc and gfortran versions. Ones shipped with system are always good. You can not compile fortran files with C compiler (or java compiler or whatever)

[brada4]

Or you can re-package static .a library using ar, syntax is much like tar.

[christoph-conrads]

@burlachenkok There were changes to the format of the ELF object files in binutils 2.26 for x86-64 architectures. If you create object files with code from binutils 2.26 or later for x86-64 and if you try to use this object code with binutils 2.25 or earlier, then you will get the error

unrecognized relocation (0x2a) 

There are two ways to avoid this problem:

• Use only binutils 2.26 or later.
• Create object code with binutils 2.25 or earlier.

The changes to binutils-gdb were made in commit 56ce. The binutils-gdb changelog mentions the update. Note that the integer identifier of the new relocation type is 42 (0x2a, see include/elf/x86-64.h, line 84).

[burlachenkok]

@cconrads-scicomp Thanks for answer. If I will move to new version of binutils 2.26 or later then It will be fine in my dev machine to build library.

But then will it be possible to loader with old version to load my shared library or no?
Or ld from binutils has nothing in common with ld-linux.so?

[brada4]

You just need to assure same version of binutils is used throughout all build, and complete build happens on oldest system you are trying to target.

[christoph-conrads]

@burlachenkok

Loading shared libraries should work irrespective of the binutils version used to create the library;

• ld is part of binutils and links object files to create new binaries whereas
• ld-linux.so is part of glibc and invoked at run-time right after program execution starts.

[brada4]

You need to build on old (even unpatched) system to have old glibc/pthread import (it versions symbols), in worst case after 10 years you will need to install -compat package for respective library.
You can also abuse Ubuntu's alternatives mechanism and let user select best BLAS/LAPACK https://github.com/xianyi/OpenBLAS/wiki/faq#debianlts
I.e. build against reference netlib BLAS, then just swap it to the best one (in some cases that could be ACML, MKL, or CUBLAS)

[martin-frbg]

Maybe LATL https://github.com/langou/latl a C++ template implementation of LAPACK and BLAS can be used for the "missing" parts, if you are willing to add C++ code to your fortran-free project.

[martin-frbg]

From an unrelated discussion at lapack, there is also SLATE http://icl.utk.edu/slate/, also written in C++

[lm8]

martin-frbg mentioned converting LAPACK files with f2c. I noticed a clapack mentioned at netlib.org. Would that work with OpenBLAS? I'm looking for a Fortran free solution that might work with Android. I also ran across FLENS ( http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html ) which mentions a C++ version of LAPACK. Haven't had a chance to try it yet, but I'm wondering if that would provide an alternative option.

[brada4]

You need to search yourself for functions you need.
There is no complete full lapack in C around, but good chance finding needed functions rewritten.

[martin-frbg]

Depends on your needs - OpenBLAS itself does not require LAPACK. The CLAPACK from netlib is (an old version of) LAPACK converted with f2c so should work as long as you do not need any of the functions that were added to LAPACK in recent years. I have no experience with any of the C++ based projects mentioned above, but expect they will be reasonably complete (mhh... flens and slate appear to implement subsets of even the "old" LAPACK only as yet?) and probably offer at least C bindings.
The f2c way is probably the simplest, though both readability and performance of the converted code will suffer and there is also a libf2c to drag around... If the main issue is that you have no fortran compiler on your Android system, cross-compiling a "complete" OpenBLAS on Linux could be a sensible option as well.

[martin-frbg]

Recent discussions at Reference-LAPACK mentioned LAPACK++ https://bitbucket.org/icl/lapackpp and its possible integration into netlib, but this appears to be a C++ API similar to LAPACKE on top of the original FORTRAN code, not a rewrite.

[danielcjacobs]

I'm trying right now to just bring in a single file (dgesv.c) from CLAPACK to build with the rest of CBLAS.

Here's my procedure:

1. Copy dgesv.c to OpenBLAS/lapack-netlib/CBLAS/src
2. Copy the 2 header files it includes (f2c.h and blaswrap.h) to OpenBLAS/lapack-netlib/CBLAS/include. These files are list a list of typedefs and defines.
3. Build and install OpenBLAS with ONLY_CBLAS=1

When I do this, the symbols from dgesv.c (specifically looking for the dgesv_ function) aren't found anywhere in libopenblas.so.

I think I need to add dgesv.c to the makefile, but I'm not sure exactly where I would do that, or if there's an alternative option

[danielcjacobs]

But if anyone has an answer for how to build OpenBLAS with all of CLAPACK, that would be even better

[martin-frbg]

nothing in lapack-netlib gets compiled when NOFORTRAN=1, the cblas there is only present because it comes with the netlib Reference-LAPACK sources.
Actual OpenBLAS CBLAS is generated from the sources in interface, you could try putting your CLAPACK file there and adding it to the Makefile in the same way as you see it done for cblas_xerbla (add dgesv.$(SUFFIX) to CXERBLAOBJS in the top part of the Makefile and copy the build instructions at the very end, replacing "cblas_xerbla" and "xerbla" with "dgesv". For getting this into the shared library as well, you will need to add your "dgesv" to exports/gensymbol - again where you see cblas_xerbla is probably a good place to add it) Obviously this gets messy the more you need from LAPACK, and some functions depend on others. It is probably possible to build clapack separately without its own BLAS, telling it to use the already ibstalled OpenBLAS

[danielcjacobs]

That was very helpful, thank you!

[emmenlau]

Dear @martin-frbg and all, I've just come across this issue when trying to build OpenBLAS for Android. Do I understand correctly that PR #3539 would add support for a number of additional symbols to pure CBLAS (without the need for Fortran)? That would be great!

[martin-frbg]

CBLAS should be complete as-is, what the PR would do is enable the LAPACK functions (where the canonical C interface is LAPACKE). What was discussed above for DGESV was just a dirty trick to get a single LAPACK function interfaced with OpenBLAS after converting it from Fortran to C.

[danielcjacobs]

That looks awesome! Thanks for implementing this feature, can’t wait to use it!