- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear All
I have a library I am trying to port to ifort on MacOS, and about half way through, the following happens:
[ 47%] Building Fortran object CMakeFiles/common.dir/WR_RECORDER.f90.o
[ 48%] Building Fortran object CMakeFiles/common.dir/WRITE_HTML_TEST.f90.o
[ 48%] Building Fortran object CMakeFiles/common.dir/COMMON_MODS.f90.o
[ 48%] Building Fortran object CMakeFiles/common.dir/SPECIAL_CONSTANTS_subm.f90.o
Error copying Fortran module "recursive". Tried "RECURSIVE.mod" and "recursive.mod".
make[2]: *** [CMakeFiles/common.dir/recursive.mod.stamp] Error 1
make[1]: *** [CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2
The slight problem is that I have no idea what this Fortran module "recursive" is!
On my Mac I am using CMake to create a make file which contains no reference to a recursive.mod. I have no file called recursive.f90 or a module called recursive.
I do use small number of recursive routines, and many of these seem to have compiled just fine.
I have no idea what to do next, I am using
ifort (IFORT) 17.0.5 20170817
Thanks in advance
Norman
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK I have sorted this out:
My code contained the statement (in the body of a submodule):
module recursive function blah(i)
and this was generating the problem with a module called "recursive"
In the Mac version, the problem goes away with a simple change to
recursive module function blah(i)
Please note that both versions have the originally anticipated effect in the Windows version of the ifort compiler
Please also note that the Mac version was quite happy with the interface declaring the function to be a module function and recursive in either order, the problem only arises in the submodule body.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry about the formatting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Might be that for some reason the module recursive failed to built, hence it could not be copied.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Juergen
Thanks for the very prompt reply
Is there a Fortran system module called "recursive", should I be telling Cmake where to find it, and where is it likely to be?
N
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, there is no system module called recursive. Recursive must be the name of one of your modules in the library that you try to build.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No I have no module by this name.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error message definitely comes from the cmake build system. So at least this one believes there is a module named recursive. I think that the automatic assessment of your Fortran dependencies failed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I can reproduce the problem in a smaller example I will submit it as a support request, but you are right, it may be Cmake struggling to understand the dependencies - interestingly there is no mention of a module called recursive.* in the output makefile.
Thanks
N
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK I have sorted this out:
My code contained the statement (in the body of a submodule):
module recursive function blah(i)
and this was generating the problem with a module called "recursive"
In the Mac version, the problem goes away with a simple change to
recursive module function blah(i)
Please note that both versions have the originally anticipated effect in the Windows version of the ifort compiler
Please also note that the Mac version was quite happy with the interface declaring the function to be a module function and recursive in either order, the problem only arises in the submodule body.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Can you comment on the Fortran standards as it related to post #9 (problem statement)?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim -
I'm not Steve, although I used to play him on TV sometimes ... :-)
Are you asking if the two declarations are considered, by the standard, to be the same? I would say "Yes'. Procedures defined by subprograms (Chapter 15.6.2 in the F2018 draft) are allowed a number of keywords as a prefix, and the order is not mandated.
I thought the issue here was CMake, not ifort, am I misunderstanding?
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Lorri
After a lot of investigation, it turned out that the problem is completely an ifort for Mac problem and has nothing to do with Cmake. ifort for Windows does not show this issue either.
(I had originally suspected Cmake/make because of the message from ifort about a module called recursive, but this turns out to be ifort not understanding the statement described above. Juergen, in kindly trying to help, had sent me down what turned out to be a blind alley with a red herring at the end.)
Thanks
Norman
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The question I have is: does the standard state:
[keywords] "module function" name (quotes indicates unbroken words)
and/or
"module [keywords] function" name
and/or
[keywords] "module [keywords] function" name
The IVF documentation (implies) "module function" (quotes indicates unbroken words).
Do you have a link to the TV show? ;)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"MODULE" is listed as one of the keywords, and the keywords are not ordered, so "recursive module" should be the same as "module recursive".
Should be.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Taken to extreme ...
function real foo() (I know it is [prefix [prefix]] function foo() )
none implicit
eh?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, Lorri has often performed as a double for me on TV. It's an uncanny resemblance, almost as good as Ed Wood Jr.'s wife's chiropractor filling in for Bela Lugosi in "Plan 9 from Outer Space."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note I had a similar problem involving CMAKE and interfaces for recursive module functions on my Mac, but in this case the compiler was gfortran. From the symptoms I came to believe that the problem was not with gfortran (or fort for the poster), but rather with CMAKE. CMAKE has a crude Fortran parser in order to determine the module dependencies used to structure the Makefiles it creates. In this case when it sees module starting a line it appears to think that the next word following module has to be the name of a module, and it sets up the makefiles expecting that the name.mod file will be generated. This worked until submodules were introduced in F2008, that in turn resulted in the use of module as a keyword in some interface blocks.
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page