I am using Visual Studio 2015 Update 3 and Intel Parallel Studio XE 2016 Update 3 Composer Edition for Fortran Windows.
I am working with code that mixes Fortran 77 and C. I am trying to upgrade the build to the latest versions of the compiler and Visual Studio IDE.
I have a scenario similar to the following: Two libraries (stubs for DLLs) call them a.lib and b.lib. I have 4 Visual Studio projects, 2 to build the lib stubs and 2 to build the DLLs. The lib projects are Fortran projects (vfproj) and the DLL projects are C++ projects. The DLL projects just depend on object files so use the Microsoft linker instead of the Fortran linker xilink. The stubs are built before the DLLs to deal with circular dependencies.
b.lib exports a fortran subroutine called sub_one. sub_one uses DEC$ ATTRIBUTES C and to set the arguments as references. A mod file is generated with the interface definition. A b.def file exists that contain the name "sub_one" all lower case, no ordinal value.
a.lib imports this fortran subroutine sub_one. a.lib is also built from Fortran code.
a.lib is build with the following property: Diagnostics -> Language Use Warnings -> Check Routine Interfaces to No. Then the linker for a.DLL reports that it can't resolve the external dependency SUB_ONE@# where # is a ordinal value. It is in the build b.lib but lower case, no ordinal value.
If a.lib is build with Diagnostics -> Language Use Warnings -> Check Routine Interfaces is set to Yes, then linker for a.DLL looks for and finds lower case sub_one in b.lib and it is happy. No unresolved external dependencies.
I am curious why a Diagnostics flag would affect compiling and linking.
It shouldn't, but sometimes does. Please try the 2017 version - if that also fails, please supply a test case that demonstrates the problem. If need be, submit it through Intel Premier Support.