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++