On 2018-07-08 07:29, Dominik Gronkiewicz wrote:
> With introduction of Fortran modules, a problem arose how library
> developers should package and distribute their libraries. In C/C++, a
> typical way is to install a binary blob to /usr/lib and a header (.h
> or .hpp) to /usr/include which allows to compile applications with
> that library. In Fortran, .mod file is required to compile the code
> that uses a module, but that file is compiler and architecture
> dependent (not even portable against different versions of the same
An operating system distribution, almost by definition, provides a set
of rules and conventions for how software that is compatible with that
distribution needs to be packaged. Different distributions will have
Binary compatibility is by no means guaranteed across compilers/compiler
versions and compile options. This is not Fortran specific. If you
compile something in a way that is incompatible with the rules and
conventions of the distribution, then you have the same set of problems,
regardless of language, with the binaries. Module files (if that's how
a compiler implements modules) are just a more visible manifestation of
One of the rules and conventions of a distribution may well be that
there is *a* single system Fortran compiler/version/compile options
combination, and if you are using something that is incompatible with
that, then you are out of luck. This is certainly the approach taken
for for other languages.
> There are at least 4 approaches that I am aware of:
> 1. For code that uses some limited subset of language (no deferred
> shape arrays etc) only the binary file is needed.
The limited subset may be more limited than you think - it depends on
> 2. One can distribute and install module files. The problem is that
> the user is stuck with the exact compiler that was used to build the
> library (usually gfortran). Another issue is that there is no
> standard location for those files. In Red Hat based systems (RHEL,
> Fedora, Scientific Linux), this directory is
> /usr/lib64/gfortran/modules (replace lib64 with lib for 32 bit
> systems), and this is the installation path I assume in my
As above, the practical consequence of the rules and conventions of the
distribution may be that you are stuck with that compiler.
(That directory seems silly - consider what would happen if packages had
conflicting names for modules. I would instead expect a package
specific directory under /usr/lib or similar. But then again, it is up
to the distribution, perhaps one of their rules and conventions is that
modules used in packages cannot have conflicting names.)
> 3. One can write procedure interfaces in a "header" file which then
> is "included" in the program. This is the way how FFTW does it. It's
> a bit ugly but if the library contains only subroutines (no
> constants, derived types etc), it does its job.
As above, binary compatibility may still be an issue, it depends on
> 4. Submodules -- very similar to 3, but more "Fortran way", and
> allows for using all language features. The downside is that only
> very recent compilers support it (and compilers 2-3 years old have
> very buggy support). Also, it is not completely clear to me how to
> include that in the compilation process.
If a distribution requires a particular compiler/version/options, this
is a non-issue.
> I only have experience with Linux, so I have no idea which of these
> approaches is the best portability wise.
> What is your take on the subject? Thanks in advance for opinions and
> suggestions! Dominik
What are the rules and requirements of the distributions that you work with?