Is it possible to use a stdlib library generated with one compiler to link a program using a different compiler?

Hi everybody. I really like the stdlib initiative. I wish it would have been available 10 years ago when I started using Fortran. I have been testing it when I get some time.

I use cmake to compile stdlib. After fixing issue #310, now when I use cmake the module files are installed here:

include/fortran_stdlib/GNU-10.2.0
or
include/fortran_stdlib/Intel-20.2.1.20201112/

This way I can separate module files from different compilers: intel or gfortran. This is perfect.

However, the library is installed at lib/libfortran_stdlib.a independently of the compiler. That is, one cannot distinguish the compiler used to generate it.

The questions that arised to me are: why do you distinguish the module files but not the library file? And, does it mean that it is possible to use a stdlib generated with gfortran in a program compiled with ifort or viceversa? I think it is not possible, but I am not sure so I’d better ask here.

Welcome to the forum @Emilio

The short answer is no: Fortran libraries and module files are specific for each compiler (and sometimes compiler version).

To handle automatically different compilers, your best bet is to use fpm. You can access stdlib with fpm using @lkedward automatically generated repository or wait that this PR gets merged.

For Fortran we don’t have ABI compatibility between compiler, therefore it is currently impossible to combine libraries compiled by different Fortran compilers, except for using bind(C) procedures.

The module file location is a different story, there is no standard location to put those and putting them straight into the include directory is harmful, because depending of the installation prefix those modules might not get picked up correctly again, which makes the library unusable.

Our imperfect solution so far is to put the module files in some subdirectory and make it accessible by exporting it as include-directory in the pkg-config and CMake config file. The directory name is predictable enough to guess from another build system, but using the config files is safer. Still, it doesn’t distinguish between compilers and different ABIs this way. Therefore, versions of stdlib compiled with different compilers have to be put in different installation prefixes at the moment.

We shift the burden of correctly managing the environment to the user in some way. If you have an idea for improving this in our CMake setup, let us know. An option might be to have subdirectories in the library directory as well and export additional library search paths from the config files, but then we have to think about a sane way for detecting the compiler we want to use in the config files.

The alternative is to build stdlib on-demand in your build system, this is possible in CMake with some boilerplate and of course quite easily with fpm.

Thank you both for the answers. In general I always use gfortran, so this souldn’t be a problem for me. I was just curious about that behaviour.

I don’t know how to improve the CMake setup, I started using it one year ago. Anyway Fpm looks great and it is probably the way to go.

2 Likes

What would be nice would be if compilers could load the headers directly from an archive (.a) file. That way all the compiler-dependent stuff would be in one place. Could fpm could be endowed with some functionality to support this behaviour?