Issues at LINK step with IVF 18

[Cameron]

Are there any known issues with IVF 18 with linking against dependent c/c++ projects?

We recently upgraded some of our solutions to be built with IVF 18 and Visual Studio 2017.  Looks like project dependencies are not being respected, or that the LINK step is not looking in the correct directories for *.lib files.  I can see the /OUT command, and it's looking in several places that normally would not be used (i.e. C:\Windows\Debug).  I do not see this behavior with Visual Studio 2013 and IVF 15.

These dependent C projects are built without error during a full rebuild, and the *.lib files are present where they should be.  I've checked, double checked, and even recreated the solution files from scratch to avoid in-place upgrade headaches from Visual Studio.

[Steve_Lionel]

There is a project property "Link dependent libraries" that needs to be on. It should be set to Yes by default.

[Cameron]

Steve Lionel (Ret.) wrote:

There is a project property "Link dependent libraries" that needs to be on. It should be set to Yes by default.

My DLL project has this option set to yes.  Manually swapped to no and back to yes, no effect.

[Steve_Lionel]

If the C++ project is a DLL and you are trying to link in the export library, C++ doesn’t make that visible to “parent” projects and you’ll have to add it manually. A static library will still work.

[Cameron]

Steve Lionel (Ret.) wrote:

If the C++ project is a DLL and you are trying to link in the export library, C++ doesn’t make that visible to “parent” projects and you’ll have to add it manually. A static library will still work.

We have one Fortran project designated for DLL creation; C/C++ projects are not creating any DLLs.  For my bigger solution, there are 19 projects included in total: 9 are C projects and 10 are Fortran.  Some of these C projects are static libraries, while others are utility projects that assist in various ways (e.g. exporting symbol definitions to their own *.def file).  For Fortran some of the projects are Static Library, others perform their own utility functions, and one is DLL.  I've included a build process below for a smaller solution that also has this issue:

Solution ABC:

• Project A - Fortran Application Project
• Project B - C Static lib project
• Project C - Fortran Application Project

Build order based on dependencies: Project B --> Project C --> Project A

Project A depends on both Project B and Project C.  I cannot fully link in Project A until manually building Project B despite all settings looking as they were in Visual Studio 2013.  My solution is generating a temporary *.rsp file during this link step, is it possible that something is happening here?

[Steve_Lionel]

Sorry, I've gone as far as I can without seeing your actual solution and project files.

The .rsp is just something VS uses to invoke tools (linker, etc.) Can you at least attach the project files (.vfproj/.vcxproj) and the solution file? Also the buildlog.htm for the parent Fortran project that does the linking. Put them in a ZIP and attach to a reply here.

[Steve_Lionel]

Interesting. It's trying to link in license.lib, not from the output directory of the License project, but from the directory of the main project. I'll try some experiments to see if I can reproduce this, but it may be a couple of days.

[Cameron]

Were you able to make any discoveries with this?

[Steve_Lionel]

No, sorry.

[Cameron]

Steve Lionel (Ret.) wrote:

Sorry, I've gone as far as I can without seeing your actual solution and project files.

The .rsp is just something VS uses to invoke tools (linker, etc.) Can you at least attach the project files (.vfproj/.vcxproj) and the solution file? Also the buildlog.htm for the parent Fortran project that does the linking. Put them in a ZIP and attach to a reply here.

Sure thing.  I've attached the simpler example above in a zip (including its BuildLog.htm).  The only modification I have done is add the /VERBOSE flag for the link step.

Thank you for the assistance with this.