we are experiencing a very odd behaviour with Visual Studio (2015) and Intel Fortran (2017): we use the netCDF library in our programs and it turns out that the first (!) time we do a rebuild of one of the programs in the solution an object file from the Fortran interface library for netCDF is missing - typeSizes.obj, whereas the corresponding .mod is there. According to the build log, it was correctly compiled. Of course it means that at the end things cannot be properly built.
But if we rebuild it again, the object file is actually present and the whole build succeeds.
While I state here that it has to do with the netCDF library and its Fortran interface, I cannot be sure - it is just that it happens with a source file from that library. I cannot remember ever seeing it with any other program or programs though.
The phenomenon is repeatable: every time I start Visual Studio and rebuild one of the programs in the solution, the first rebuild fails and all subsequent ones do the job properly. It is also very odd that only that one object file (but not the .mod file) is missing.
Does anybody have a suggestion as to how to solve this? It is an annoyance, not impossible to get around, but still, an annoyance.
Do a clean, then, do a full build (we expect an error)
Inspect the folder(s) where you have targeted the .mod and .obj files.
Two situations may present itself: a) only .mod is present, b) both .mod and .obj are present.
If b) then possibly your Anti-Virus intercepted the .obj creation and is inspecting it during the link phase. Look at the timestamps to see if significantly different.
If a), write down the time stamp of the .mod file. Then perform your second build, examine the time stamps of both .mod and .obj to see if both got rebuilt.
Does this occur with and without IPO enabled?
I've seen this occur in older versions of IVF when you update a version of IVF and use formerly created Solutions/Projects. The fix for this is to copy your existing solutions and projects into a different place, delete the solutions and project, then create new ones. Keeping the old ones permit you to perform a side-by-side settings comparison for getting your options set properly.
Additional note, if your modules have circular dependencies this behavior can also happen.
thanks for the prompt reply. I tried this: Clean, Build ... and got a satisfactory build result. The files typeSizes.obj and typeSizes.mod have the same timestamp (I have checked it down to the second).
Now I have done a Rebuild (after the Build was completed) and I see a number of files are left over - three .obj files and two .mod files. Others in that directory (x64\Release) have been removed.
We do not use IPO and most if not all options are set to default.
Hm, the one thing that is different with this project than all the others in this solution is that the directory in question contains both a .vfproj and a .vcxproj file ... your remark about old solutions/projects triggered me to contemplate that as a reason.
>>.vcxproj is a C/C++ Project type.
I generally use (select) Create New (sub-)Folder for Project as opposed to placing the Projects within the same folder as the Solution. IIF you have selected to keep the Projects in the same folder as the Solution (and co-resident with the IVF Project), and if there are dependencies between the C/C++ and IVF projects then there may be and issue (although I cannot state this for a fact).
An additional thing to check is the Project dependencies of each project in your solution. For each project: Right-Click on Project in the Solution explorer and select Project Dependencies. Then check the boxes according to what you know are the proper dependencies.
Arjen Markus wrote:
.. Does anybody have a suggestion as to how to solve this? It is an annoyance, not impossible to get around, but still, an annoyance.
You possibly have a Visual Studio solution with N number of Fortran projects (vfproj) and M other projects (e.g., C/C++ vcxproj, etc.). An option for you to try is:
I have the same problem as Arjen Markus.
How can I solve the Problem? I'm using VS2015 and Intel parallel 2018, when I rebuild the solution the typesizes.obj and the netcdff.lib (which was created in previous solution build) is deleting whereas the corresponding .mod is there.
>>when I rebuild the solution the typesizes.obj and the netcdff.lib (which was created in previous solution build) is deleting whereas the corresponding .mod is there.
Does the corresponding .mod file have a future date?
Is there a placement of the .mod files other than in default locations?
Also, the compiler include paths must include the compiler's output path for the .mod files (else you may be "including" a different .mod file than expected).
The behavior is symptomatic of having a circular dependency (mod A dependent on mod B dependent on mod A).
Dear Jim Dempsey, thanks for your response.
No, typeSizes.mod file doesn't have a future date.
I think the placement of the .mod files is in default location, I'm compiling Delft3d open source codes, which is downloaded by SVN.
about the compiler include paths, I haven't done any manual differences in codes. It's the first time that I'm working with open source codes and I don't know enough about them.
Yes I think that behavior is symptomatic of having a circular dependency.
Is there any solution or setting in VS to stop cleaning the built items or I have to do with Makefile.am or common. am?
Also I couldn't find the setting of IPO.
I would be grateful for your guidance.
With circular dependencies a file fails to compile at the first attempt because it needs something that has yet to be compiled. The thing is usually data or routines from a module that is being used by the failed file.
There should be some clues in the build log file.
You would know if IPO was being used as the compiler spits out an IPO message to the output window after very file compile.
I would suggest you:
1) Look at the build dependencies (order) for the configuration you are having the problems with.
screen-shot this, or write it down in notepad.
2) Perform a clean
3) Manually select each module starting at the ones without dependencies (to your modules), then perform compile (select module source in solution explorer, right-click, compile)
4) work up the build dependencies (reverse order) doing the same
At some point you may receive an error message indicating a problem with your dependencies