Link FMUs with static versions of Lapack and Blas

[Rüdiger Franke]

Recently dgesv has been added to 3rdParty and is copied to source code FMUs. Nevertheless FMUs are still linked against -llapack and -lblas provided by the system. The static versions of the system libs cannot be used because they are compiled without -fPIC.

Couldn't static PIC versions of these libs be generated and added to lib/x86_64-linux-gnu/omc for FMU builds?

The Windows build must contain lapack and blas locally too. Could possibly a cross-platform solution for local lapack and blas be found?

[Martin Sjölund]

The static FMUs are compiled with -fPIC. We cannot generate static PIC versions of lapack and blas because we copy the files for cross-compilation (so we need one for potentially every platform). The static source FMUs are not linked using -llapack -lblas on my system. And anyway I am changing the code to use autoconf to detect if the system has a lapack/blas available. The problem is that for example Ubuntu does not support installing the i386 amd amd64 version of lapack at the same time (and the mingw64 package is missing lapack); so source code is needed regardless.

I will try to remember that the static version of lapack/blas might be compiled without -fPIC. This needs to be detected by autoconf if they are used.

[Rüdiger Franke]

My example linking -lblas and -llapack was using the regular

translateModelFMU(Model, version="2.0");

How do you generate static source code FMUs?

Cross compilation would be the next but one step. It would be great if the Windows build of OpenModelica used a gcc >= 4.9 and provided cross compilation for linux64 target.

[Martin Sjölund]

You generate the static source FMUs with a debug flag. Cross-compilation is working using a Linux host. Note that GCC is not a cross-compiling compiler (but clang is!). This means you need one additional installation of gcc for each target you want to compile for (but you only need one installation of clang for all targets). Regardless, you need one set of headers + linkers for the cross-compilation targets.

@adrpo: It would be nice if mingw64 had packages for the cross-compilation targets and we ship a script to install these even if they are not included in the installation by default.

[Adrian Pop]

@rfranke: We will switch to gcc 5.2 soon.
@rfranke & @sjoelund.se: I don't know if there are any gcc packages on Windows for cross compilation on Linux, but I'll have a look.

[Martin Sjölund]

Look for packages named arm-linux-gnueabihf-gcc, x86_64-linux-gnu-gcc, etc :)

[Rüdiger Franke]

The following Makefile can be copied and executed in OMCompiler/3rdParty/dgesv:

all:
	for f in lapack/*.c blas/*.c libf2c/*.c; do gcc -Iinclude -fPIC -c $$f; done
	ar rcs libdgesv.a *.o

Then one can generate FMUs replacing -llapack -lblas with -ldgesv. The size increase is moderate (200k if the whole lib was linked).

Having 3rdParty/dgesv in place, wouldn't it make sense to generate and exploit libdgesv.a for FMI export in order to get rid of external lapack/blas dependecies?

[Martin Sjölund]

No, you cannot do that. dgesv only includes dgesv, but MSL requires the full lapack in some places. Also, it doesn't help cross-compilation or source-code FMUs where you need to have the source-code available.

Also, -fPIC is not available on all platforms that we compile code for.

[Rüdiger Franke]

Well, of course the Makefile shouldn't be added as is, but integrated with the autoconf / cmake mechanism to adapt compiler name and options like -fPIC to the platform at hand. The dgesv sources are still available for cross compilation -- it would then be the same that are also used for regular FMUs. The missing lapack functions are an argument. But shouldn't they be added for cross compilation anyway?

[Martin Sjölund]

You are also concerned about performance. The main purpose of these files is to make something that compiles. It will use the generic BLAS, which is quite slow in comparison. So the FMU should try to compile against the system lapack whenever possible.

[Rüdiger Franke]

OK. Let's stay with the dynamically linked system lapack then.

[Rüdiger Franke]

It appears that atlas comes with static PIC versions of lapack and blas. One may install the package libatlas-base-dev and link with:

-L/usr/lib/atlas-base/atlas -Wl,-Bstatic -llapack -lblas -Wl,-Bdynamic

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed