I am working with code that has the following structure:
compA.F90:
module compA
use abc
…
end module
abc1.F90:
module abc
…
end module
I compile abc1.F90 and get abc.mod
I compile compA.F90 and get compa.mod
So far so good.
Now I compile the actual program:
prog.F90:
program prog
use compA
…
end program
And I get “PGF90-F-0004-Unable to open MODULE file abc.mod (abc1.F90: 10)”
I can solve the issue by specifying an additional -I option to point to the directory where abc.mod is located when compiling prog.F90. However, I don’t understand why this needs to be done. Why does the compilation of prog.F90 depend on having access to abc.mod? After all, I already compiled compA.F90.
The associated bigger issue here is that say I have compB.F90 that depends on its version of abc.mod (like from a abc2.F90 file). How could prog.F90 use both compA and compB and not get confused?
Is the answer that the Fortran standard simply does not support the case I am describing, and other compilers that do support it are doing this outside the standard’s restrictions?
Thank you for any insight you might provide on this!
The associated bigger issue here is that say I have compB.F90 that depends on its version of abc.mod (like from a abc2.F90 file). How could prog.F90 use both compA and compB and not get confused?
Perhaps I’m not clear on what you’re asking, but if both compA and compB both use abc, they would share the same abc module. They won’t get separate copies.
Why does the compilation of prog.F90 depend on having access to abc.mod? After all, I already compiled compA.F90.
You shouldn’t need to the include path to the abc.mod in this case. Something else is going on.
On a side note, you may want to consider using the “-module <mod_dir>” flag so all modules will be stored in the same directory.
And I get “PGF90-F-0004-Unable to open MODULE file abc.mod (> abc1.F90: 10> )”
This error looks like it’s occurring when compiling the file “abc1.F90” not “prog.F90”.
Can you please cut-and-paste the full contents of the files along with compiler command line and output from the compilation? That would help a lot in understanding what the issue is.
I should have mentioned that there is an associated directory structure that makes this possible in principle (and works for e.g. Intel and GCC). Here the case with more details:
.:
CompA prog.F90
./CompA:
ABC compA.F90 compA.o compa.mod
./CompA/ABC:
abc.mod abc1.F90 abc1.o
Going bottom up I first compile inside of CompA/ABC:
pgfortran -c abc1.F90
Then I go up a directory and compile:
pgfortran -I./ABC -c compA.F90
So far so good. Now I go one step further up, and try to compile prog.F90. This is where I get the error!
pgfortran -I./CompA -c prog.F90
PGF90-F-0004-Unable to open MODULE file abc.mod (prog.F90: 3)
PGF90/x86-64 Linux 19.4-0: compilation aborted
So while I am trying to compile prog.F90, I am getting an error about not finding “abc.mod”.
So here I tried to post the code, which all 3 files no more than a few lines of code, but the editor does not allow me to post (I always receive “403 - Forbidden” error when I preview or try to submit). Please let me know how I can post legal Fortran code here.
Anyway, I can of course get prog.F90 compiled by also adding the -I./CompA/ABC path:
pgfortran -I./CompA -I./CompA/ABC -c prog.F90
However, this is what bothers me. Why does the compilation of prog.F90 depend on having access to the abc.mod? And again, in the bigger picture there may be a CompB with its own ABC subdir that defines a different abc.mod. It seems to me that this detail of what is happening below CompA and CompB should be hidden from the prog.F90 layer. But as you can see, I don’t get around this if the compiler needs access to the abc.mod when compiling prog.F90 - which is strange.
So here I tried to post the code, which all 3 files no more than a few lines of code, but the editor does not allow me to post (I always receive “403 - Forbidden” error when I preview or try to submit). Please let me know how I can post legal Fortran code here.
Unfortunately we’ve been having problems with this and we’re not sure why. Our webmaster is aware of the issue and investigating.
In the mean time, can you send the example code (in the directory structure, if you can) to PGI Customer Service (trs@pgroup.com) and ask them to forward them to me?
I was able to reproduce the error here and have added an issue report (TPR#27597). We’ll have our compiler engineers take a look and see if we can improve this.
In the meantime, I would suggest using the “-module <mod_dir>” flag so all the generated modules are saved in the same directory and thus eliminate the need to have multiple include directories.
Thank you Mat for the TPR. I will be looking forward to seeing what the compiler folks think about this.
Again, the bigger issue is that for a real application the prog.F90 level wants to use a CompA and CompB module, each of which is using a different module named ABC underneath.
In the even bigger picture I might not even know all the modules CompA and CompB are using underneath - and on the prog.F90 level hopefully I would not have to worry about it at all. In fact CompA and CompB might have their own build systems so I cannot even collect all the module files easily into one location. All I have on the prog.F90 level when using them are the CompA and CompB modules. As for linking, the object files would be wrapped into archive libraries and liked as sort of black boxes against the prog.F90.
Thanks again for forwarding this to the engineers and setting up the TPR.
-Gerhard
I don’t think this one is a bug, you’ll just want to specify “-module path/to/where/modules/are” to tell the compiler where to load the module file from.
$ pgfortran -c abc1.F90
$ cd ..
$ pgfortran -c compA.F90 -IABC
$ cd ..
$ pgfortran prog.F90 -ICompA CompA/compA.o CompA/ABC/abc1.o
prog.F90:
PGF90-F-0004-Unable to open MODULE file abc.mod (prog.F90: 3)
PGF90/x86-64 Linux Rel Dev-r179069: compilation aborted
$ pgfortran prog.F90 -ICompA CompA/compA.o CompA/ABC/abc1.o -module CompA/ABC/
prog.F90:
hsw3:PGI-Testing$ ls
a.out CompA prog.F90 prog.o
$ ./a.out
This is from abc1.F90, for caller: compA.F90 for: prog