Unnecessary linking

[gib]

Following up on my previous post about having to rebuild when no code has changed, I see now that the compiler is not invoked, just the linker. For some reason VS thinks that the program needs to be linked. Here is the link command line:

/OUT:"Debug/FileRead.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"D:\ArrayVisualizer\FileRead\debug\fileread.exe.intermediate.manifest" /DEBUG /PDB:"Debug/FileRead.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"D:\ArrayVisualizer\FileRead\debug\fileread.lib" AvFRTd.lib ole32.lib oleaut32.lib

Can someone see anything funny here? The only extra piece of info is that all the projects with this problem (Array Visualizer samples) have been converted from an earlier version of VS (to VS2005). I had to add the include and library paths to the compiler options. I'm using 11.0.072

Please help!

[Paul_Curtis]

Quoting - gib

... all the projects with this problem (Array Visualizer samples) have been converted from an earlier version of VS (to VS2005)...

I experienced similar behavior on projects converted from DevStudio to VS2003 and then to VS2008, which seemed to indicate that the dependency checker was not working since the compiler could not figure out the proper compilation order for multiple modules. The problem disappeared when I rebuilt the projects from scratch, re-associating all the source and resource files manually.

[gib]

Quoting - Paul Curtis

I experienced similar behavior on projects converted from DevStudio to VS2003 and then to VS2008, which seemed to indicate that the dependency checker was not working since the compiler could not figure out the proper compilation order for multiple modules. The problem disappeared when I rebuilt the projects from scratch, re-associating all the source and resource files manually.

It would be surprising if there were a dependency issue, since the programs are very simple, some just a main, but I'll try that.

BTW, do you live in Cuzco? ;-)

[gib]

I deleted and recreated the project. Same behaviour.

[jimdempseyatthecove]

Gib,

One potential cause for this behavior is one of the files in the dependencies (for some reason) exists with a future date. Files now can have many dates. When you copy a file from a desktop to a server and/or back or between systems some of these dates can get misinterpreted (especially when one of those systems does not support the particular date attribute).

In the old days (~1990) when this would happen you would run a program called TOUCH to reset the "newness" of files to "right now". I do not know if new SDKs have a TOUCH that goes through an entire solution including dependencies (some of which may be read-only).

Since your solution (project) is small you could get a list of what is being referenced in the link and then check the timestamps on all the date/time attributes (date created, date accessed, date modified, date whatnot, etc...) something may show up. For the questionable files, try copying the file to a temp folder on the same systemthen copying it back to the expected place.

If that does not find the problem

Perform a build (link). Use Windows Explorer, Search C: for files with dates of today, sort results by date/time, record listed date and times of top most file.

Repeat above

Check for files newer than prior top most file. Is (are) any of those files in your link dependencies?

Good luck hunting.

Also, ifany of your linking libraries are on a server, dates and times can get out of wack in the translation of dates between the server and the desktop.

Jim Dempsey

[gib]

Quoting - jimdempseyatthecove

Gib,

One potential cause for this behavior is one of the files in the dependencies (for some reason) exists with a future date. Files now can have many dates. When you copy a file from a desktop to a server and/or back or between systems some of these dates can get misinterpreted (especially when one of those systems does not support the particular date attribute).

In the old days (~1990) when this would happen you would run a program called TOUCH to reset the "newness" of files to "right now". I do not know if new SDKs have a TOUCH that goes through an entire solution including dependencies (some of which may be read-only).

Since your solution (project) is small you could get a list of what is being referenced in the link and then check the timestamps on all the date/time attributes (date created, date accessed, date modified, date whatnot, etc...) something may show up. For the questionable files, try copying the file to a temp folder on the same systemthen copying it back to the expected place.

If that does not find the problem

Perform a build (link). Use Windows Explorer, Search C: for files with dates of today, sort results by date/time, record listed date and times of top most file.

Repeat above

Check for files newer than prior top most file. Is (are) any of those files in your link dependencies?

Good luck hunting.

Also, ifany of your linking libraries are on a server, dates and times can get out of wack in the translation of dates between the server and the desktop.

Jim Dempsey

Thanks for the resonse, Jim. It is a puzzle. The project links three libraries, AvFRTd.lib ole32.lib oleaut32.lib. The latest date on these library files is 2006. I just did the search on C: for files modified today (didn't know about that capability, very useful), and the latest timestamp on those files is earlier than the last build time. Similarly on D: (where the project resides) I can account for all the files with the build time timestamp.
I wonder if there is a way to see how VS determines that a link is required, some "verbose" switch?

[Steven_L_Intel1]

Unfortunately, there does not seem to be a way to get Visual Studio to expose the logic of its dependency analyzer. I'll admit that I've seen this too. It's rare, but when it does happen it seems difficult to resolve. Perhaps creating a new solution will work.

[Paul_Curtis]

Quoting - Steve Lionel (Intel)

Unfortunately, there does not seem to be a way to get Visual Studio to expose the logic of its dependency analyzer. I'll admit that I've seen this too. It's rare, but when it does happen it seems difficult to resolve. Perhaps creating a new solution will work.

Wait a minute. Back when IVF was first introduced as the upgrade/successor to CVF, one of the main improvements claimed (by Steve, IIRC) was that the dependency checker would henceforth be a wholly Intel component, created and maintained by Intel, and thus the future would be much better than when we were forced to use whatever Microsoft had supplied with DevStudio. This is important to me because I have large multimodule projects with very complex dependencies, and have had lots of problems with automatic dependency checking, which basically did not work at all until I upgraded to IVF11/VS2008 and also manually rebuilt all my solutions (it now works as expected for building/rebuilding/linking in all combinations). Perhaps the magnitude of this prospective improvement was overstated.

[Steven_L_Intel1]

There are two aspects to this. One is the source dependency analyzer, which reads source files and looks for things such as INCLUDE and USE. In CVF, this was a rudimentary thing layered on top of the C++ analyzer, but in IVF it's our own. But then there's the part of Visual Studio that determines whether the EXE is out of date, and that, I don't think, we have hooks into. I may be wrong and will ask our IDE experts next week.

[jimdempseyatthecove]

Dates within files has become a grey area (there are 4 or 5 different date attributes now). Assuming dates you observed are the ones used in the dependency checker (date created, date modified, date read, date archived, date ...) and they are correct.

I've had Fortran projects thay would perform recompiles of some files that should not have compiled. The only way to fix this was to delete the solution and project files and re-create them. I think this was a case of an internal database of dependencies (in IVF) being stale and including as a dependency something that no longer exists.I assume you tried a Clean then Rebuild All, then test with Build to see if it completes with doing nothing.

Since you describe the problem as re-link (not recompile of some file then re-link) it would seem like a .lib issue or .obj newer than .exe issue.Have you checked your manifest settings?

What happens when you create a new "Hello World" from scratch?


Jim

[gib]

Quoting - jimdempseyatthecove

Dates within files has become a grey area (there are 4 or 5 different date attributes now). Assuming dates you observed are the ones used in the dependency checker (date created, date modified, date read, date archived, date ...) and they are correct.

I've had Fortran projects thay would perform recompiles of some files that should not have compiled. The only way to fix this was to delete the solution and project files and re-create them. I think this was a case of an internal database of dependencies (in IVF) being stale and including as a dependency something that no longer exists.I assume you tried a Clean then Rebuild All, then test with Build to see if it completes with doing nothing.

Since you describe the problem as re-link (not recompile of some file then re-link) it would seem like a .lib issue or .obj newer than .exe issue.Have you checked your manifest settings?

What happens when you create a new "Hello World" from scratch?


Jim

Progress! All my other projects behave as expected, e.g. a simple "hello world" program. BUT when I add AvFRTd.lib to the list in Linker > Input > Additional Dependencies, the relink problem surfaces. So there is something funny about the Array Visualizer debug library. Presumably it was built with a dependency that no longer aapplies, a library file that no longer exists, perhaps.

I could move this issue to the Array Visualizer forum, but since AV is no longer supported there might be no recourse.

Thanks Jim and others for helping.

Gib

[Paul_Curtis]

Quoting - gib

... when I add AvFRTd.lib to the list in Linker > Input > Additional Dependencies, the relink problem surfaces.

Instead of doing it that way, try adding the library to your project as a component, using Add --> New Item after right-clicking on the project name.

(BTW, Cuzco is a nice place to visit, but I wouldn't want to live there.)

[gib]

Quoting - Paul Curtis

Instead of doing it that way, try adding the library to your project as a component, using Add --> New Item after right-clicking on the project name.

(BTW, Cuzco is a nice place to visit, but I wouldn't want to live there.)

Yes! That fixed it. Thanks of lot.

Gib