Using a Fortran90 module in a C/C++ application

Question

I have the source file of a big module written in fortran90 with some type definitions, some interfaces, some functions and subroutines. I am able to compile it and to use it inside a normal fortran program.

But since I have always used C/C++ and I don't know so much of fortran I would like to use this module inside a C/C++ program. That is using its data types and calling its functions/subroutines on them.

Is it possible? How can I do this? What are the various steps I have to achieve? Are there some exhaustive tutorials on the web (I didn't find so much with a brief google search..)

Answer 1

The search call fortran from c gave me several links to various tutorials and examples.

Some highlights:

Fortran calls are by reference, so you get to use pointers/the address-of operator a lot.

Fortran routines are usually exported with some simple name mangling. You can either find out by reading the manual or you can use nm f.o, where f.o is a compiled fortran file.

Using the routine names obtained you need to create a C header file with declarations for the routines you want to call.

When linking you need to link with the fortran library, -l<name of fortran lib>.

Answer 2

Fortran 2003 adds specific provisions for interoperability with C. You can find a run-down in the GCC docs. If your Fortran code does not use those features, however, (as indeed it probably doesn't) and you are not prepared to modify it to do so, then the answer depends strongly on your Fortran and C tool chains. Some issues involved include

• name mangling. Many Fortran compilers implicitly add one or more underscores to declared function names, and most convert identifiers either to all-lowercase or all-uppercase
• array indexing. Fortran array indices start at 1 (by default), and multi-dimensional arrays are indexed in the opposite order of the one used by C.
• string arguments. Fortran has explicit-length strings. The way they are represented in the argument list of a function varies from compiler to compiler. Most use a char * and pass the length as a separate argument, but other arrangements have been employed. Also, the length argument may follow immediately after the pointer, or it may be append at the end of the argument list.
• strings generally. Fortran has explicit-length strings. Positions past the end of valid data should be blank-filled.
• pointers. Fortran 95 has no raw pointers. It does have something called a pointer, but it is not directly analogous to a C pointer.
• scalar data types. The mapping from C data types such as int and double to Fortran data types depends somewhat on the compilers involved. It is not guaranteed that all types provided by one compiler have analogous types among those known to the other compiler.
• user-defined types. Without the C interop features, it is difficult to ensure that the layout of user defined types will be the same, even if you can match up the types of the components correctly.
• argument-passing conventions. In addition to the fact that Fortran uses call-by-reference, Fortran 90 provides for array-passing modes that don't map to anything in C. Not all functions use those modes to pass arrays, but you are unlikely to be able to call functions that do (they aren't even supported by F03's C interop features).
• don't mix Fortran external I/O with C external I/O. It's difficult to get right.
• you will probably need to link the Fortran runtime library. Its name varies from compiler to compiler.

That's not an exhaustive list, but it covers most of the common issues. Which of them you need to deal with depends on the packages you are trying to connect.

Previous to F03, Fortran / C interop was typically provided on a product-by-product, toolchain-specific basis. Often a set of specific interface functions was provided on one side or the other, or both. There is still a great deal of such code out there, and it might be a good strategy for you, too. Also, there are tools that try to help sort out the mess. The GNU Autotools have some support for it, for instance, covering much more than just the GNU toolchain. Alternatively, you may need to inspect some object files to determine how to approach some of those issues.