Using .MOD files in Fortran programs

Hi,

I am trying to make use of a common directory that should avoid duplicating code, i.e. only make use of the USE <module_name>. The test program are as follows:

1. conversions_mod.f95 and
2. test_module.f95
3. user environment variable: mod_path=h:\ftn95\user\modules

Compile and link message/error 😢

Compiling file: test_module.f95 H:\FTN95\test\test_module.F95(3) : warning 242 - Variable I has been given a value but never used Compilation completed with no errors. Linking... WARNING the following symbols are missing: CONVERSIONS_MOD!STR2INT H:\FTN95\test\CheckMate\Win32\test_module.obj (H:\FTN95\TEST\TEST_MODULE.F95) Creating executable: CheckMate\Win32\test_mod.exe Linking completed.

The test project only includes the test_module.f95 file while the .MOD and .OBJ files are in the directory defined by mod_path. Why do I get missing symbols if the mod_path is set?

I hope to solve this and for once begin to uderstand how to use libraries.

Regards Jacques

Here is the test code:

program test_module
  use conversions_mod
  integer :: i
  i = str2int('230')
end program




module conversions_mod
  implicit none
  contains

  INTEGER FUNCTION STR2INT(STR)
    implicit none
    character(len=*),intent(in) :: str
    integer :: num
    READ(str,*) NUM
    STR2INT = NUM
    return
  end function str2int

end module

mod_path is a compiler switch. It is the linker that cannot see the given obj file.

You could copy the missing file or perhaps use a 'Reference' in the project settings, or customise the linker switches in the project settings.

Hi Paul,

what linker switch should I use so that the linker search my common .obj path. I would like to avoid copying the files. The aim is to have them central, since if I start copying them I have to re-copy them after each change or update of the .obj.

Is the switch then only for a project or is it then valid in general?

Jacques

I am not sure how to answer your question. As far as I know there is no equivalent to mod_path in SLINK but I would have to check this out.

There are two standard approaches:

1. Add your module source files to the project so that they are in the build process or

2. Create a DLL for your modules and then Reference your DLL from the main project.

Either approach should avoid this kind of problem.

Hi Paul,

thanks for your tip. You do not know how exactly to answer, and I do not know how to exactly state my problem 😢

Add source files to project

When distributing our internal libraries, would mean we have to distribute our source files which we do not like to do.

DLLs

I am familiar with this idea but never did this before :!: It sounds very good, but I am missing some steps.

If I search through the forum for topics regarding libraries (.dll, .lib and .mod) I get the feeling that many has the same problem as I do. The lack of an example demonstrting from it from the beginning to the end.

This is clear since there are a lot of [u:7c43ad79d6]views[/u:7c43ad79d6] and no replies for dll topics. The Silverfrost FTN95 help mention dlls but there is no complete example of how to axactly do this.

Even searching trough the web the only help is pieces here and there. Do you perhaps have some example of creating and using a dll with Plato3? I think that this could be something for the Knowledge base section 😃

Jacques

Here are some basic instructions:

Create a New Project from the File menu and select 'Fortran DLL'.

Open the Properties from the Project menu and make sure that, in the Linker options, 'Export all' is selected.

Add your source files and build the DLL.

To use the DLL, create another project for a 'Fortran application'. Add your application source files to the project and create a Reference to your DLL using the Project Explorer window. You will also need to use the .mod files that were formed when you built the DLL.

I will provide another post after this with some general advice.

It is simpler if you can avoid using modules in a DLL because users have to be supplied with the .mod files and these are compiler dependent.

If you avoid using modules in your DLL then there is at least a chance that the DLL could be used with other compilers.

Under Fortran 77 there were no MODULEs and no INTERFACE statements. DLLs contained only EXTERNAL functions and subroutines that did not require an interface. This approach is still available.

MODULEs are provided to give a degree of object orientation. There is little value in simply packing a group of unrelated routines into a module.

If a routine requires an INTERFACE then this can be provided explicitly rather than via a USE statement. Interfaces can be placed in a file and added to the application source file via an INCLUDE statement. This approach is compiler independent.

Hi Paul,

thanks for the tipps. Your comments is very helpfull and I believe to understand the differences and usage of DLL, INTERFACE, EXTERNAL and INCLUDE better.

Missing .obj files

In my previous attempts to use a central directory with .mod files I discoverd that the object files are missing during compilation. I then realised that not only the .mod files but the .obj files must be available as well. And the not so nice thing about the .obj files was that it must be in the directory where all the other project .obj files are. Can work, but there are better solutions to solve this.

Modules

Since I discovered modules I used it quit a lot. This is especially usefull for defining user type variables. As long as the module is used in a single program it seems to be very effective. Since these are compiler dependant it seems be carefull decision whether to use it or not. Especially if the aim is to create DLLs.

INCLUDE

This seems to seems to be a very good option to use in future. Rather than using the USE statement I can now have a central file like library.ins for example with all my user type variables. These files are central and I have the option to create DLLs and standalone programs without any problems. Thus using INCLUDE has the following advantages:

library files are central, through the f95include environment variable the source is maintained in a single file DLLs is shipped as a single file without the need to include the .mod library files can be used in other projects without difficulties

Jacques

Hi Paul,

you mentioned in a previous post that you will find out if there is a switch to specify the path for pre-compiled .obj files when using slink. Could you find something usefull?

Is it possible to specify it in Plato environment?

Jacques

SLINK uses three environment variables:

PATH LIB SCCLIB

Try adding your object file folder to one of these.

Hi Paul,

I tried these as environment variables and still get the following message after compilation:

Compilation completed with no errors. Linking... WARNING the following symbols are missing: XMLPARSE!XML_ERROR H:\FTN95\xml\xmlreader\Debug\Win32\xmlreader.obj (H:\FTN95\XML\XMLREADER\XMLREADER.F90) Creating executable: Debug\Win32\xmlreader.exe

If I use Plato, where should I set these variables? In the documentation I could not find any information that explains exactly where and how I should set/change these variables.

Thanks Jacques

Environment variables are machine settings.

Under Windows XP, click on the Start button. Select 'Control Panel'. Select 'System' Click on the 'Advanced' tab. Click on 'Environment Variables' Find or create (say) LIB in the lower pane. Click on Edit. If the value is not empty, type a semi-colon (;) at the end of the list. Type in the name of your folder.

Hi Paul,

I tried each of the three environment variables that you mentioned. However, none of this seems to solve my problem. I still get the same error message when linking. The object files are still not seen by the linker.

According to the documentation the LIB environment variable is used by SLINK and provides a search path for Win32 library files. It seems like that SLINK does not search for .obj files here.

How can I use a single object file in multiple programs without copying the .obj file each time. Or what other solution is there available?

Jacques

You can use a dynamic (DLL) or a static library. A DLL is usually preferred as already noted in this correspondance.

/mod_path works together with /link on a command line.

That is, you can use both together to compile and link a single file that references a module in a different folder.

To do this from Plato you will need to create your own command from the 'Tools' menu. The standard build process will not do this for you at the moment.

Instead of using /mod_path on the FTN95 command line (directly or via a Plato build), you can create an environment variable named MOD_PATH and provide the name of a folder or a list of folders (that contains the .MOD files).

Then you will not need to use /mod_path on the command line.

You can use the environment variable when building in a DOS box (using /link) or when building a single program file (without creating a project) in Plato.

If you create a project in Plato then you must add a 'Reference' for each relevant .obj file by using the 'Project Explorer' window. Alternatively you can build the module(s) into a .DLL or .LIB and reference the library instead.

Hi Paul,

if I choose a static library (.lib) which includes a module definition, how is this then handled in a new project?

As a result I have the following 2 files for a xml parser:1. xmlparse.lib2. xmlparse.mod If I add xmlparser.lib as a reference to my project to I still need the xmlparse.mod file?

I think my questions are very simple and the solution, but it is difficult to exactly unterstand or implement the library concepts without an example. A small example in the documentation will defenitlay help 😉 Trying all the possible combinations is also very time consuming.

Jacques

You need the .MOD files at compile time because they provide information for the USE statements in your code.

You would need a reference to the library at link time because this information is required by the linker. For static libraries the object code from the library is built into your executabel by the linker. For a dynamic library the linker adds information to the executable so that the library can be linked dynamically at runtime.

Hi Paul,

I created some static library from the command line using slink slink -archive:xmlparser.lib -addobj:xmlparser.obj

Then from Plato Project → Add References.. I linked to the xmlparser.lib file. This works ok for my application.

For better understanding could you please explain the following:

1. When should I use a static library and when a dll?
2. During a build is the source compiled and link or what happens during a biuld?

Thanks Jacques

You can also create a static library via a project in Plato.

1. Use a DLL when your library is shared by many executables and you want the executables to be small.

2. To build means to compile any files that have been changed and then link. You can also separately compile any single file.