in two directories I have two different, independent Fortran 90 programs, and I want them to share certain routines that use some variables defined in modules. In other words, I have a directory dirA with program prgA.f90 and a couple of routines in an extra file sub.f90, and these routines use some stuff from a module in the file modA; all of them reside in dirA. In another directory, dirB, I have the independent code prgB.f90 that is supposed to use routines from sub.f90 and hence needs modules that define the stuff needed by it. For technical reasons, I cannot use the modules from modA in dirA directly, but write a variant of it, modB, with the same module name and containing the variables of interest with the same names as in modA as well as other variables only used by prgB. Will the routines from sub.f90 work with modA in the executable of prgA and with modB in the executable of prgB?
I have partly tried to adapt my codes to this, and the compiler seems to accept it somehow, but I'm not sure if it will really work and not produce garbage results in spite of compiling seemingly ok.
Basically the question is this: Can I share functions USEing certain modules between different programs if I ensure that the modules have the same name and have a subset of variables in common, or do the modules USEd by the functions have to be exactly the same for both programs?
Thomas
If I understand correctly then what you are doing is just fine.
When you build progA the compiler encounters, on tackling sub.f90, a statement such as use globals. At that point the compiler will look for a file called globals.mod which it should, by that point, have created by compiling the module source. Of course, that module source need not be in a file called globals.f90 but that's neither here nor there. The module source might, for example, be in a file called globals_for_a.f90.
When you build progB the compiler encounters, on tackling sub.f90, a statement such as use globals. At that point the compiler will look for a file called globals.mod which it should, by that point, have created by compiling the module source. Of course, that module source need not be in a file called globals.f90 but that's neither here nor there. The module source might, for example, be in a file called globals_for_b.f90.
So long as the compilation for each program finds the right source for globals.mod everything should compile as you wish. You've chosen to divide your source files across a number of directories but that's not strictly necessary; a make file with suitably defined targets could build either program or both however you organise the source files and directories.
Note that almost all of this is outside the concern of the Fortran standards, it's more a question of how compilers and compilation work.
Related
I have a module module1 in a file called mymodule.f90. What should I do in order to make module1 usable like fortran intrinsic module?, i.e. it need only be called in a use statement (use module1) in any programs, subroutines, or functions that use it but I don't need to link /path/to/mymodule/ when compiling those procedures.
I use gfortran, but possibly in the future I will also have to use the Intel fortran compiler.
So maybe I'm misunderstanding you, but you want to use a module without having to tell the compiler where to find the .mod file (that contains the interface definitions for whatever module1 exports), or the linker where the object code can be found?
If so, for GFortran the solution is to download the GCC source code, add your own module as an intrinsic module, and then build your own custom version of GFortran. As a word of warning, unless you're familiar with the GFortran/GCC internals, while this isn't rocket science, it isn't trivial either.
For Intel Fortran, where you presumably don't have access to the source code of the compiler, I suppose you're out of luck.
My suggestion is to forget about this, and instead tell the compiler/linker where your .mod files and object files can be found. There are tools like make, cmake etc. that can help you automate this.
When you compile mymodule.f90 you will obtain an object file (mymodule.o) and a module file (mymodule1.mod). The compiler needs to have access to the module file when it compiles other files that use mymodule1, and the linker needs to have access to the object file when it generates the binary.
You don't need to specify the location of intrinsic modules because they are built in into the compiler. That will not be the case with your modules: you may be able to set up your environment in a way that the locations of your files allow the compiler to find the files without explicitly specifying their paths in compilation or linking commands, but the fact that you don't see it does not mean it's not happening.
For the Intel compiler, the answer is given by https://software.intel.com/en-us/node/694273 :
Directories are searched for .mod files in this order:
1 Directory of the source file that contains the USE statement.
2 Directories specified by the module path compiler option.
3 Current working directory.
4 Directories specified by the -Idir (Linux* and OS X*) or /include (Windows*) option.
5 Directories specified with the CPATH or INCLUDE environment variable.
6 Standard system directories.
For gfortran I have not found such a clear ordered list, but relevant information can be found in
https://gcc.gnu.org/onlinedocs/gfortran/Directory-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
It should be clear to you that a compiler won't be able to understand module files created by other compilers, or even by different enough versions of the same compiler. Therefore, you would need a copy of your "always available" module for each compiler you use, and if you are using multiple versions of a compiler you may need up to one per version - each of them in a different directory to avoid errors.
As you can see, this is not particularly practical, and it is indeed far from common practice. It is usually easier and more clear to the user to specify the path to the relevant module file in the compilation command. This is quite easy to set up if you compile your code using tools such as make.
Finally, remember that, if you make such arrangements for module files, you will also need to make arrangements for the corresponding object files at the linking stage.
I'm trying to clean up a fortran make process for distribution. Currently, two libraries are made, and then the executable is compiled linking to the libraries and including the module files. I see from previous answers (Distribute compiled fortran library with module files) that you can't get rid of the module files and that they can be different for every machine and compiler. This is very annoying.
However, the code in my libraries are made up entirely of modules. It seems like I don't need the library part at all; I can just include the modules. I've tried this and it does compile and run on small examples.
Will this always work (when all I have are modules in the libraries)? Is it best practice? Should I instead consider rewriting my libraries NOT to use modules so I can avoid all these compiler dependencies and only distribute the lib*.a files? Is that what this document is referring to by using submodules (which no one supports static lib with many modules)
It really depends on the features you have in your library. Does it have only a couple of declarations? Then the .mod files would suffice, but why not distribute the source in such a simple case?
Are all your public procedures simple enough, so that they do not require an explicit interface and they are outside of modules? Then you don't need any .mod files.
Do you have a simple public module or an include file with the public API and the rest is private? You can then distribute the source of the API module or the include file. I would recommend to place just the interface blocks and other declarations in this module.
Be aware of one important problem. You can get away (using interface locks or similar) with avoiding the non-portable .mod files, but if the procedures are using some more advanced argument passing, their ABI is often NOT portable between different compilers or even some compiler versions. You would the be able to compile it and get mysterious crashes when calling your library.
Submodules can change it all, but actually I do not expect they will solve portability between compilers. The user of your library will still need the same compiler you had. It is true that interfacing the closed source software will be easier, but not more portable between compilers.
You can link either from a library lib*.a, or from object files. Both will be at least platform dependent and so more difficult to distribute than source code. library file might have the advantage of fewer files. In either case, linking from lib*a or object files, you can present your code to the user as a library of procedures to call. If you don't want to distribute your source code, then you will have to compile for however many platforms you support. Modules are a major advantage of modern Fortran, automating the checking of procedure actual and dummy arguments. Compared to, for example, C header files, they have the advantage of being automatic, but the disadvantage of producing a compiler-dependent intermediate file. If you are providing procedures to other programmers, it would seem a bad idea not to provide them with this interface checking. If you want to hide your source code, then you could write interface blocks describing the procedures and distribute only this source for them to compile.
I would like to be able to share a FORTRAN 95 module without sharing its source code. Is it possible to do so (maybe by sharing the .MOD file)? In case this is relevant, I use Silverfrost FTN95 compiler on Plato. So far, I only manage to make this work by using the source code of the external module. Here is an example:
file: module_test.f95
module TEST
contains
subroutine 1
code...
end module TEST
file: main_program.f95
include "module_test.f95"
program MAIN_PROGRAM
use TEST
implicit none
code...
end program MAIN_PROGRAM
So, would it be possible for someone to use my module TEST without having my file module_test.f95 nor the line include "module_test.f95" on the main code?
Thanks a lot!
You could provide two things. 1) Compiled object code, possibly in library form. The disadvantage is that this would depend on compiler, OS, perhaps compiler version, and so could be large burden to support. 2) Instead of providing the source code so that others could use the module, you could write equivalent interface descriptions of your routines. This, at least, is at the source code level and would not be compiler dependent. It would some work to write and would have to be maintained if you changed the arguments of any of your procedures.
The solution I am using is, as M. S. B. recommended, to compile the module in library form. I am explicitly showing how I am doing this in case this might be helpful to someone, as this is what I did not know in those days.
First, one needs to compile the module module_test.f95. Using the gfortran compiler, this can be accomplished by the command gfortran -c module_test.f95. This will create two files, module_test.o and module_test.mod. These are the compiled module files that can be shared without sharing the source code.
Now to the main program. For it to make use of the module, one still needs to add the line use TEST but no include <source code>:
program MAIN_PROGRAM
use TEST
implicit none
<...code...>
end program MAIN_PROGRAM
Now when compiling the main program, one must include the location of the .o module file in the command. In the case above, it would be gfortran main_program.f95 module_test.o (supposing that module_test.o is on the same folder as the project). This will compile the main program using the module without the need for its source code.
I'm having trouble understanding if/how to share code among several Fortran projects without building libraries or duplicating source code.
I am using Eclipse/Photran with the Intel compiler (ifort) on a linux system, but I believe I'm having a bigger conceptual problem with modules than with the specific tools.
Here's a simple example: In ~/workspace/cow I have a source directory (src) containing cow.f90 (the PROGRAM) and two modules m_graze and m_moo in m_graze.f90 and m_moo.f90, respectively. This project builds and links properly to create the executable 'cow'. The executable and modules (m_graze.mod and m_moo.mod) are stored in ~/workspace/cow/Debug and object files are stored under ~/workspace/cow/Debug/src
Later, I create ~/workplace/sheep and have src/sheep.f90 as the program and src/m_baa.f90 as the module m_baa. I want to 'use m_graze, only: ruminate' in sheep.f90 to get access to the ruminate() subroutine. I could just copy m_graze.f90 but that could lead to code getting out of sync and doesn't take into account any dependencies m_graze might have. For these reasons, I'd rather leave m_graze in the cow project and compile and link sheep.f90 against it.
If I try to compile the sheep project, I'll get an error like:
error #7002: Error in opening the compiled module file. Check INCLUDE paths. [M_GRAZE]
Under Properties:Project References for sheep, I can select the cow project. Under Properties:Fortran Build:Settings:Intel Compiler:Preprocessor I can add ~/workspace/cow/Debug (location of the module files) to the list of include directories so the compiler now finds the cow modules and compiles sheep.f90. However the linker dies with something like:
Building target: sheep
Invoking: Intel(R) Fortran Linker
ifort -L/home/me/workspace/cow/Debug -o "sheep" ./src/sheep.o
./src/sheep.o: In function `sheep':
/home/me/workspace/sheep/src/sheep.f90:11: undefined reference to `m_graze_mp_ruminate_'
This would normally be solved by adding libraries and library paths to the linker settings except there are no appropriate libraries to link to (this is Fortran, not C.)
The cow project was perfectly capable of compiling and linking together cow.f90, m_graze.f90 and m_moo.f90 into an executable. Yet while the sheep project can compile sheep.f90 and m_baa.f90 and can find the module m_graze.mod, it can't seem to find the symbols for m_graze even though all the requisite information is present on the system for it to do so.
It would seem to be an easy matter of configuration to get the linker portion of ifort to find the missing pieces and put them together but I have no idea what magic words need to be entered where in the Photran UI to make this happen.
I confess an utter lack of interest and competence in C and the C build process and I'd rather avoid the diversion of creating libraries (.a or .so) unless that's the only way to make this work.
Ultimately, I'm looking for a pure Fortran solution to this problem so I can keep a single copy of the source code and don't have to manually maintain a pile of custom Makefiles.
So can this be done?
Apologies if this has already been documented somewhere; Google is only showing me simple build examples, how to create modules, and how to link with existing libraries. There don't seem to be (m)any examples of code reuse with modules that don't involve duplicating source code.
Edit
As respondents have pointed out, the .mod files are necessary but not sufficient; either object code (in the form of m_graze.o) or static or shared libraries must be specified during the linking phase. The .mod files describe the interface to the object code/library but both are necessary to build the final executable.
For an oversimplified toy problem such as this, that's sufficient to answer the question as posed.
In a larger project with more complex dependencies (in my case, 80+KLOC of F90 linking to the MKL version of LAPACK95), the IDE or toolchain may lack sufficient automatic or user-interface facilities to make sharing a single canonical set of source files a viable strategy. The choice seems to be between risking duplicate source files getting out of sync, giving up many of the benefits of an IDE (i.e. avoiding manual creation of make/CMake/SCons files), or, in all likelihood, both. While a revision control system and good code organization can help, it's clear that sharing a single canonical set of source files among projects is far from easy given the current state of Eclipse.
Some background which I suspect you already know: Typically (including ifort) compiling the source code for a Fortran module results in two outputs - a "mod" file that contains a description of the Fortran entities that the module defines that the compiler needs to find whenever it sees a USE statement for the module, and object code for the linker that implements the procedures and variable storage, etc., that the module defines.
Your first error (the one you solved) is because the compiler couldn't find the mod file.
The second error is because the linker hasn't been told about the object code that implements the stuff that was in the source file with the module. I'm not an Eclipse user by any means, but a brute force way of specifying that is just to add the object file (xxxxx/Debug/m_graze.o) as an additional linker option (Fortran Build > Settings, under Intel Fortran Linker > Command Line). (Other tool chains have explicit "additional object file" properties for their link stage - there may well be a better way of doing this for the Intel chain.)
For more involved examples you would typically create a library out of the shared code. That's not really C specific, the only Fortran aspect is that the libraries archive of object code needs to be provided alongside the mod files that the Fortran compiler generates.
Yes the object code must be provided. E.g., when you install libnetcdf-dev in Debian (apt-get install libnetcdf-dev), there is a /usr/include/netcdf.mod file that is included.
You can now use all netcdf routines in your Fortran code. E.g.,
program main
use netcdf
...
end
but you'll have link to the netcdf shared (or static) library, i.e.,
gfortran -I/usr/include/ main.f90 -lnetcdff
However, as user MSB mentioned the mod file can only be used by gfortran that comes with the distribution (apt-get install gfortran). If you want to use any other compiler (even a different version that you may have installed yourself) then you'll have to build netcdf yourself using that particular compiler.
So creating a library is not a bad solution.
I am trying to run sample Fortran code on Xcode 4.3 using a 64-bit compiler and it will not build correctly. The main problem is that despite my best efforts, I cannot get the separate .f90 files to interact with each other, thus code like
USE ElementModule, ONLY : ElementType
will not work. Does anybody have any answers regarding how to get the separate .f90 files to read each other. I'm aware you have to include specific modules, but my search hasn't given me any straight answers regarding what those specific modules are.
Normally when F90 code compiles, it generates 2 files: an object file and a mod file. When compiling subsequent modules, the mod files are used for the USE statements.
If you have circular dependency, then you have to build two or more times. Best to avoid circular dependency if you can avoid it.
The mod files are normally picked up by the same directive that tells the compiler where the include files are.