Plato CANNOT FIND 'mod' files

😢 If this is one of those 'already answered' topics, please direct me to the 'answer', because it is completely invisible to me. I have seen quite a few querries on the same subject, but absolutely not a single working example of how to 'use' and 'find' modules with Plato.

The ONLY way I can get Plato to actually recognize a properly-compiled 'mod' file is if it is in the SAME directory, which is not an acceptable way to have to work. NO other compilers which I have been able to use have a problem with 'finding' mod files elsewhere on the system. Apparently this is too much for Plato, however.

In the 'help' documentation, the clear claim is made that all one must do is set an 'environment variable' called 'MOD_PATH' to the modules directory, and Plato/Silverfrost will properly 'use' the modules specified. I have not been able to make this work a single time. As I said, ALL the examples I have seen via quick online searches fail to show a working process of Use (module) and any kind of working method to include it in the project.

Note that I am not interested in building a 'dll' or lib.

Further, on the 'project tree', I can see .f90 source files which I have added to a project. I am without a clue as to how to 'include' files, mod or otherwise, into the 'include' folder in the tree. I have also tried to specify an 'include' statement in 'Tools - Command Line Options' with no success. Nor is there any hint of how to 'include' files in any of the help documentation that I can see.

How in the world can one do this seemingly very simple task?

Thanks for comments.

jack

Jack,

Have you tried the default path for modules. See SET. Mine is: mod_path=C:\Program Files (x86)\Silverfrost\FTN95\include

You could copy your .mod files into this directory and see what happens.

The next attempt could be to change this environment variable. For PLATO to see the change you might need to change the value in Control Panel > System > ... I am not sure if FTN95 requires other modules in this directory.

Another option is to see if PLATO supports multiple directories, as with %PATH% functionality. I don't know.

A few ideas to try,

John

The other possibility is, if you are using a Plato project, there is a option to set the mod path via an FTN95 command line option.

/MOD_PATH works for me.

I have tried all of these, with the exception of trying to jam modules into some 'default' directory - which surely should not be required for a usable compiler.

Setting a system-wide environment variable, 'MOD_PATH', OR 'mod_path' creates the same errors 'no path to module', etc, with no help at all, I'm afraid.

Using other compilers (not mine) I have found the main problem to be LINKING with the module object files. While I have been able to get mods to link on another Linux machine with gfortran, this also seems to be nearly impossible with Plato. In linux, I had to go through the (unbelievably tedious) process of compiling each input source file into an object file; this required a 'modpath', relatively less complicated - only required the '-I<path>' include directive to the directory with '.mod' files. Then it was further necessary to 'link' ALL the object files AND all the module object files, with yet another path to the same include directory, with '/*.o' on the end.

Plato WILL 'compile' all my files with USE statements, using 'release64' mode. It then announces the compilations all complete. The 'module.o' and 'module.mod' files are all in the project directory, so I assume the compile part worked ok.

Linking, however, is another story entirely. On a subsequent 'build' command, plato announces blithely that 'no such .o files or path exists', even when all the .o module's are in the source directory, and in every directory down on the tree to the 'release' folder including all the 'source.o' files. It is simply incapable of finding them, as I said in my first post.

It is particularly frustrating to have Plato announce, depending on what I have set up as 'command line options', that the '*.o' modules I have specified (and which it DID find, miraculously) are 'not of proper module format'. Note that these modules are commercial library modules which have worked just fine on other compilers. I have been using them since about 1996. The present day Fortran crop of compilers seems to have been crippled by the picky-picky direction of modern fortran, however. Also, those compilers no longer run on newer windows versions. That's why I was trying out S-frost. I'm beginning to think the fortran 'committees' have accomplished nothing but the suicide of fortran, once a great language.

I have spent considerable time reading the plato 'help files', which discuss all these things 'sort-of', without ever making any clear statements about how to actually DO the linking of module files. One particularly interesting portion of the 'help' files says to 'include' the 'INCLUDE' statements in the 'source' (f90) files. This is not something I am familiar with and I doubt it is relevant or even correct.

There is NOTHING in the Plato help system which answers my first question, 'how to INCLUDE any files into the 'include' folder in the program tree?' I cannot find ANY mention of this other than the obtuse reference above, which makes Plato an entity of its own in the F90 compiler world, if even correct.

I was thinking about purchasing the Silverfrost compiler, but with this kind of complete confusion I just don't think it woud be money well spent.

f66 (1970) /f77/f90/f95 C/C++ Pascal Basic Assembly programmer

I am not familiar with .o files being used with SLINK. Aren't .o files Linux or gFortran files ? Your problem may be .mod files that are incompatible with SLINK. Try regenerating the .mod files using FTN95.

John

Your problem may be .mod files that are incompatible with SLINK. SLINK (and other linkers) do not read module files. The .mod files are used only by the compiler, and only when compiling source files containing USE statements. To see this for yourself, compile all the source files of a project, and delete (or put away) all the .mod files before calling the linker.

I still think it is a valid question: If you have .o files and .mod files then are they compatible with the FTN95 compiler ? It looks to me that the .mod files were not generated by FTN95 and the error message may be indicating that Plato can not find valid .mod files.

I must admit that I still do most of my program development with .obj or static .lib files. I also include in SLINK the .obj file that is generated when the .mod files are generated. linkers don't give a lot of friendly advice in this regard !

John

Well this is interesting. The '.mod' and '.o' files are those produced by compiling the modules WITH SILVERFROST. The SF help files say to make sure that one uses SF own object files.

I am using Silverfrost on Win 7. It produces both '.mod' and '.o' files when a module is compiled.

Silverfrost does NOT produce any '.obj' files.

What other options should I be using, if not SF's OWN files??

Still mystified here. I have yet to see any working examples. It would seem nobody is using SF to compile and link ordinary, simple F90 programs.

jack

Now I am really confused. The SF help files, under 'getting started...using plato' say:

:FTN95 is invoked from a command line and you can work directly from the command line if you prefer (see Compiler Options on a Command Line). Alternatively you can use Plato to create Win32 applications.

It also says it creates '.obj' files. Where are they? All I get is '.o' object files. I have even renamed them to '.obj' files and Plato will still not recognize them.

Do I have to use command line to get Silverfrost to work at all? I was hoping for something from the 21st century.

j

Wow. I say wow because I think the SF folks could have done a far far better job at explaining this very simple (but unbelievably tedious) task. Again, I am using 20-year old commercial modules that have worked just fine in the past. So here is what I did to get a working .exe.

First - give up on Plato. Using it for anything more than a text editor is a complete waste of time. Notepad works as well. Plato compiles to object code with '*.o' suffices.

So with command line: Must use 'FTN95' and NOT 'ftn95' (!!). So, FTN95 -c source1.f90 <CR>; then FTN95 -c source2.f90 <CR>; etc; did this first with the module source files. Care must be taken to do these 'modules' in correct order as some are interdependent. Unbelievably, they came out as .mod and .obj. Some came out in caps, some in lower case. Preserved all this.

To avoid even more confusion, I put all these compiled modules.obj and modules.mod (some came out with capital letters, preserve these) in the same directory as the f90 sources. Then, same as above, compiled-only the actual program code, all the source files, but must be done one-at-a-time otherwise SF gets confused (!!). OK now have all object files. Then must link them ALL, including the modules.obj, with SLINK. This is the only time SF did not bomb with more than one file on the command line.

That gave me a working .exe, which works in a dos box.

Well, that's the only way I could get it to work. None of this 'MOD_PATH' stuff did anything to help, at least with Plato.

Maybe now some of it can be streamlined, and maybe someone else will get something out of this.

jack 3/25/2015 - good luck people

There seems to be lots of confusion here.

1. I don't know how you managed to get Plato to generate .o files. It might be possible if you have set it up to use gFortran and you have selected 'Release x64' from the main toolbar. For FTN95 you must use one of the other modes not 'Release x64'.

2. The -c on the command line is probably redundant. Commonly '/' is preferred to the minus sign and /c means /cfpp and this enables C-type preprocessing commands in the code.

3. ftn95 or FTN95 can be used. File names are not case-sensitive when using a Windows operating system.

As an inexperienced user, you might consider being a little more cautious in your criticism.

My conscience is really bothering me about this. I know it won't be enough, but I have to try again. Silverfrost has released a very good, well-working, compiler suite with thorough, well written documentation. My experiences are no reflection on them at all. Silverfrost, and the folks on this forum, have treated me with nothing but kindness, courtesy, and insightful comments. For this all, I am grateful. I wish I could say that I have responded in kind, but that isn't true. I cannot even plead 'inexperience'; there have been many warnings over time about programs 'talking to each other'. Usually I pay attention, but somehow this time, it just never occurred to me that that might be happening. But once I eliminated gfortran from the path, Plato/Silverfrost worked very smoothly and, as far as I can see, without fault. However, every bit of what I reported on here did happen while the programs were interfering. Thank you all for your insight and help, and patience. j

Thanks for the feedback and explanation.