Odd behaviour "Rebuild" - one object file missing at first run

[Arjen_Markus]

Hello,

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.

[jimdempseyatthecove]

Let's investigate:

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.

Jim Dempsey

[Arjen_Markus]

Hi Jim,

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.

[jimdempseyatthecove]

>>.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.

Jim Dempsey

[FortranFan]

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:

• Make a copy of your solution and the projects in some other folder,
• In this copy solution, strip down the projects with simple "Hello World!" type of subprograms and functions, cutting the projects down to single source files, if possible.  Make sure to retain all the solution and project settings and dependencies,  But delete all intermediate folders (e.g., Debug/Release) and all the files created by the toolchains in this copy folder e.g., *.user, *,mod, *.obj, etc.
• See if the underlying issue persists; if yes, it may be easier now to investigate the root cause.  If it's still unsolvable, post a zip of the folder here on this thread,
• If stripped down case works as expected, build back up the projects step-by-step in an order that appears in your assessment to be simplest-to-the-most-involved along with independent-projects first and the dependent ones later on.  Check at each step whether the original issue resurfaces
• Take a close look at the point where the issue pops up again - you will likely have the clue(s) to the problem at this stage to resolve the issue.
• If you are able to fully build back the solution and yet not encounter the original issue, chances are something got corrupted in your initial solution directory that has been rectified by this exercise - note this has happened with other users with VS projects and multilanguage project dependences. Your new folder then holds your sanitized solution!

[Arjen_Markus]

Thanks for all the answers. They have given me enough ideas to try out.

[MinaZakipour]

Hi Dear 

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.

@Arjen_Markus  @jimdempseyatthecove 

[jimdempseyatthecove]

>>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).

Jim Dempsey

[MinaZakipour]

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?

@jimdempseyatthecove 

Also I couldn't find the setting of IPO.

I would be grateful for your guidance.

[andrew_4619]

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.

[jimdempseyatthecove]

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

Jim Dempsey