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: