Fortran Wiki
Library distribution
This page is for discussing and documenting best practices for packaging and distributing modern Fortran libraries.
Library design
Are are there broader issues to consider when designing a library that will be distributed? What are useful naming conventions? How should the library be organized? Modules are nice because interfaces do not need to be explicitly defined but they also present a problem because the .mod files need to be distributed. –Jason Blevins, November 25, 2008
Module files
With Fortran 2008 Submodules, a library can be designed to use a parent module that defines all procedure interfaces, but no procedure bodies. It should be possible to distribute this type of parent module source file in place of a compiler .MOD files.
A primary problem for distributing a compiled library for a specific platform is that module files are compiler-specific. For Debian packages it might make sense to simply distribute GFortran .mod files but what about other cases? The -dev packages might need to be compiler specific, for example, libname-dev-gfortran.
Furthermore, what is the proper place to install the .mod files? The directoy /usr/include is reserved for C include files, and should never be used to store module files. Perhaps /usr/lib/<package>/include/ or even /usr/lib/<package>/<compiler>/? A <package> prefix should be used to prevent potential conflicts between module names in different packages.
libmpich1.0-dev is an example of a Debian package of a Fortran library. The .mod files for this are installed in /usr/lib/mpich/include/f90base/ and /usr/lib/mpich/include/f90choice/. The FoX library installs static libraries in $PREFIX/lib and .mod files in $PREFIX/finclude, where finclude is the Fortran counterpart to the include directory.
Module files are in a similar situation as Perl libraries. Fortran should follow a similar convention, for example:
/usr/lib/fortran– location of all fortran-specific files/usr/lib/fortran/gfortran-4.1,/usr/lib/fortran/ifort-11.0– subdirectories divided by compiler name and version./usr/lib/fortran/gfortran– symlink to latest gfortran version/usr/lib/fortran/gfortran-4.1/mpich-1.0– location of files matching the compiler and software version
Module files and static libraries could both be placed in the matching subdirectory. Shared libraries are more problematic. If the convention becomes well-defined, shared libraries could use DT_RPATH to define run-time library locations. This has the advantage of keeping compiler-specific binaries separate.
Are there any issues with distributing .mod files generated by commercial compilers? –Jason Blevins, November 25, 2008 (In most cases, .mod files and compiled libraries probably fall under the same distribution rules compiled executables.)
Avoiding Module files
Module files are specific to compilers and compiler versions, and are subject to dependency cascades. Fortran Module files are really not designed for libraries. The best approach for libraries is to avoid module interfaces.
Fortran compilers really do not need Module files. The alternative is to have source files available, which could be scanned at compile time the same as C headers. Unfortunately, current Fortran compilers all use module files.
Libraries can be provided without modules simply by using INTERFACE specifications. In this case, the header files are compiler-indepedent, but binaries are not. It is also possible to use F2003 ISO-C-Binding to make compiler-independent binary libraries, but prevents passing arrays by reference.
Jason Blevins (4 Aug 2010) There seem to be a few drawbacks to avoiding modules and using only explicit interfaces. I don’t think that access restrictions (e.g., private) will work outside of modules (I haven’t tested this, but that’s my reading of the F2003 Handbook). Thus, for routines that operate on abstract data types, one has to fully expose the members of the type.
Also, it’s unfortunate that libraries containing procedures with Fortran interfaces aren’t binary compatible across compilers. This doesn’t seem to be an issue in practice with C compilers, although I’m not sure if that’s just due to a high level of coordination or because it’s actually standardized. Binary incompatibility of Fortran libraries means that even if we avoid .mod files in favor of interface specifications, the resulting library itself is still compiler-dependent which precludes an easy method of packaging and distributing shared libraries, as is commonplace with C libraries on Linux and other platforms.
It appears that with either approach, a Fortran library to be packaged in binary form will be compiler-specific since the object code itself is.
Links
Links to similar discussions elsewhere:
-
fortran .mod files posted to the Fedora packaging list.
-
Re: fortran .mod files posted to the GNU Fortran mailing list.
-
Draft notes on Packaging Fortran Libraries from the Fedora Project.
-
Help on how to create a library with F90 on
comp.lang.fortran.