Linking against Fortran libraries with mixed compilers

Linking against Fortran libraries with mixed compilers

If I have a library built from one or fortran modules, is it possible to compile it with fort into object files or library archives, then link against it from a main program compiled & linked with a different fortran compiler? I know module files are incompatible, but presuming there was a way to generate an appropriate set mod files for each compiler, but the object/archive being linked against was compiled by a different compiler?

I think the answer is no, because there is no standardized Fortran ABI, or something like that, is that correct?

I ask because I want to write some install rules for my project, and was thinking that if library objects are not compatible between Fortran compilers I would install the .a and .so files as <prefix>/lib/COMPILER_ID/libmyproj and the module files as <prefix>/include/COMPILER_ID/myproj.mod

Is there a better way? Does this sound sane?

14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It depends on what the 'different compiler' is.  We are object compatible with gcc, except for some particular OpenMP constructs.  If you are linking with gcc, you may need to add -l(specific library name) to link successfully:

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version Beta Build 20140318
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

$ gfortran --version
GNU Fortran (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
Copyright (C) 2010 Free Software Foundation, Inc

$ ifort -c -fpic F95Math.f -shared -o
$ gfortran Driver.f -lifcore -ldl
$ ./a.out
 Inside getF95sin(   1.57000005245209      ) =   0.999999682973602
  Driver call, getf95sin(   1.5700000524520874      ) =   0.99999968297360220

Huh, interesting. Any hope this works for fortran Modules too? i.e. in your example if F95Math.f was actually a fortran90 module containing various data and procedures… I guess that will boil down to whether gfortran and ifort both use the same name mangling scheme for module procedures, maybe?

ifort compiled modules aren't compatible with gfortran modules. In fact, gfortran module formats vary among major versions, so the recent 4.9 release requires them to be rebuilt.

In general, you can't mix objects from different Fortran compilers. You certainly can't mix ifort and gfortran objects. Same goes for modules.

Retired 12/31/2016

Yeah, that’s what I figured, based on the fact that .mod files have their own compiler specific format… So if I have a library built from fortran modules does it seem sane to install to <prefix>/lib/COMPILER_ID/libmyproj.a and <prefix>/include/COMPILER_ID/my_mods.mod? Are there any commonly used install schemes or best practices?

I think we've talked about this before on c.l.f.  I don't think it has ever been conclusively resolved.  Shame.

I apparently tend to put the compiler qualification bits immediately after prefix, with that qualification being absent if the compilers (in combination) are the system compilers.  I think my logic was to ensure that a particular binary built with a particular compiler combination was able to access libraries built by the same compiler combination.  This logic might be illogical. 

What you suggest seems rational to me, though is there really any need for the mod and library files to be in separate directories?  They are both "binary things used for making programs", versus source code that you might read.

Thanks for the reply. I guess I need to revisit the common paths searched by compilers for mod files. My thinking for placing the mod file in `include` is that mod files are like binary c header files, and most compilers will search directories listed after the -I (include) flag for mod files. As such, it seemed (perhaps illogically) logical to me to put them there. If most compilers search standard system library install locations and/or can locate mod files in directories listed after -L then I think it would make more sense to install them alongside the corresponding library.

-L is for linker libraries. .mod files are consumed by the compiler - in Intel Fortran they are looked for in the -I locations.

Retired 12/31/2016


Izaak Beekman wrote:

Yeah, that’s what I figured, based on the fact that .mod files have their own compiler specific format… So if I have a library built from fortran modules does it seem sane to install to <prefix>/lib/COMPILER_ID/libmyproj.a and <prefix>/include/COMPILER_ID/my_mods.mod? Are there any commonly used install schemes or best practices?

For whatever it's worth, we follow essentially the same approach you suggest, most usage is on Windows platform though, but also some on Linux. We have LIB and INCLUDE defined that point to paths very similar to what you indicate; the main difference is that in addition to compiler identification, we also have some CPU architecture idenitified (e.g., suitable identifiers for 32-bit v 64-bit architectures).

Rambling some more...

I've never really understood why mod files and [#]INCLUDE'd source were treated as being the same sort of things when it came to search directories.  Conceptually, apart from "compilers need to find them" they are reasonably different things.  Perhaps a distant hangover from mod files being a bit like C headers in terms of the information they supply to the compiler.

Where ever the modules go, that directory structure might need to consider the potential for name clashes amongst modules from different packages (including name clashes between "private" modules that aren't meant to be used by the client code but which still need to be present due to the way ifort handles references in modules to other modules - an approach that annoys me).  Similarly there's also the potential for modules from different versions of a library to clash.  Perhaps that means that there needs to be a library-version name thing in the module directory hierarchy, presumably above of the compiler-version level.

I think my preferred approach ("preferred" because I've not been consistent) at the moment is to just supply the necessary explicit directory for modules for a particular library to the compilation step. 

Thanks for the additional insight. That is a very good point about modules from different packages clashing. How many kinds modules are out there defining sp, dp, wp etc? I’ll update my build scripts to install to package specific subdirectories to try to mitigate this. It would be kind of nice if one could add the dot mod files to the library archives some how. That would save a certain amount of headache. That way there would be just one thing to worry about vis a vis compiler compatibility, and would alleviate the name clash issue.


IanH wrote:

.. "private" modules that aren't meant to be used by the client code but which still need to be present due to the way ifort handles references in modules to other modules - an approach that annoys me) ...

Care to elaborate, perhaps with a simple example?  Because I wonder why we don't encounter such a problem.  Our insight into such matters is rudimentary (we're mainly technologists who need to do some coding)!   So we might be getting things "right" but in some wrong manner or not be aware of many issues.  Either way, it could be a cause for us to worry.  In our libraries, there are dozens of "private" modules that contain the actual, proprietary content, but a few "public", "interface" modules that the clients "use" to consume "methods" and "data" from the libraries.  Only these few public modules are "published" in locations that the clients reference in their IDE environments or build utilities and the clients don't have access to the "private" modules.  So why and how does it work for us!?


IanH wrote:

..Similarly there's also the potential for modules from different versions of a library to clash...

Again, an example about a clash scenario would be very helpful, if you have it handy.

Are you referring to different versions of a library built with different compiler versions i.e., same code, different compiler version?

Or do you mean same compiler, but different library code?

If the former, then the <compiler id> in path would take care of the matter.  At stated earlier, on this note Intel Fortran has been particularly good about offering module compatibility with different compiler versions.

But if it is the latter, then this is another issue we've never encountered.  Wonder if it is simply because we are usually very disciplined about not changing "interfaces" of "public methods" made available in our libraries, hence "internal" changes in library code don't cause any compiler clashes, especially on the client side.


With the caveat that I'm only a recreational user of linux, so there may be subtleties that I'm overlooking (but the following is definitely the case on Windows, where I usually live)...

Consider the TopLevel module being the one that has the bits and pieces that you intend clients to use, while SecondLevel is the "private" implementation.

$ mkdir somewhere-not-on-the-search-path
$ # build my library
$ ifort -c secondlevel.f90 toplevel.f90
$ mv secondlevel.mod somewhere-not-on-the-search-path/
$ # build client application
$ ifort -c mainprogram.f90
mainprogram.f90(2): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [SECONDLEVEL]
  USE TopLevel
mainprogram.f90(4): error #6404: This name does not have a type, and must have an explicit type.   [MODULEENTITY]
  PRINT "(A)", ModuleEntity
compilation aborted for mainprogram.f90 (code 1)

Perhaps you don't see this because your public modules don't pass through things from your private modules.  But it would appear that for libraries that don't apply that design restriction, you need to distribute the private mod files as well as the public ones, and those private mod files need to be on the module search path.

As Zaak alludes, the probability of a name clash in the naming of private modules is likely to be high - for example we've all been good little modern Fortran programmers and created one called "Kinds" so that we can easily change the precision and range of the intrinsic types when required... right?

In terms of library versions - I was thinking of different versions of the same library compiled with the same compiler release.  For example I have a couple of different versions of the HDF5 library source on my windows box, that when compiled all give a module named file named hdf5.mod (plus many "private" modules as per above).  In that case I also have different variants of the same version built with different compiler options.  I can't stick all those same named module files in the same directory.  I've built those myself which compounds the potential variation - but that version issue obviously applies to pre-built binaries too built with some sort of standard set of compilation options and backwards compatible compiler mod files too.

INCLUDE 'submodules probably make this better.txt'


Downloadapplication/octet-stream mainprogram.f90104 bytes
Downloadapplication/octet-stream secondlevel.f90144 bytes
Downloadapplication/octet-stream toplevel.f90106 bytes

Leave a Comment

Please sign in to add a comment. Not a member? Join today