Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

LINK : fatal error LNK1181: cannot open input file (wrong directory)

a_leonard
Beginner
7,309 Views

I have a solution with many Fortran projects and a few C projects.  I am occasionally getting link errors because the wrong directory is used for one of the libraries created by a C project (which wasn't changed and didn't rebuild).  The link line includes the correct location for the library, as well as an additional entry with a directory like "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE" or "C:\Windows\system32" prepended to the correct platform, configuration, and library name.

It's not always the same library that causes the problem and it doesn't happen all the time.  I can work around it by forcing a rebuild of the C library, but I'd like to know how to avoid it altogether.

This started after upgrading from VS2010 and ifort 2013 to VS2017 and ifort 2018.

0 Kudos
4 Replies
Roman1
New Contributor I
7,309 Views

This almost looks like the problem I had.  Can you look at my previous post:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/610396#comment-1874253

 

0 Kudos
a_leonard
Beginner
7,309 Views

Roman,

I think my problem is different than yours.  The IDs for the projects match the ones in the .sln file.  The solution is building fine, except for one extra entry to the list of libraries to link.

My real question is how does Visual Studio puts together the command line for the linker?

When I look at the build log I see (on one line):

  1. exactly what I see from the properties page, followed by
  2. '-qm64 /qoffload-ldopts="-mkl=parallel"' (don't know where that comes from), followed by
  3. the object files from the source files in my startup project (in the form $(PlatformName)\$(ConfigurationName)/file.obj), followed by
  4. explicitly defined libraries (full paths), followed by
  5. the libraries of the other projects in the solution (full paths, mostly in the form $(PROJECT_DIR)\$(PlatformName)\$(ConfigurationName)\$(ProjectName).lib

$(PROJECT_DIR) seems to come from the full path of the directory containing the .sln file + the relative paths for each of the projects, except that sometime it is some other path that I don't know where it comes from.  Right now it happens to be the directory defined by %VS2017INSTALLDIR%\Common7\IDE, but it has been something else.

When the bad path is there, the library is also there with the correct path.

0 Kudos
a_leonard
Beginner
7,309 Views

Here is an edited bit of the build log that shows the problem:

[
 /OUT:"x64\Double\gtsuite_dp.exe" (_deleted_options_and_files_) "D:\s\v2019_VS2017\source\GTopt\x64\Double\GTopt.lib" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\x64\Double\GTopt.lib" (_more_deleted_files_)
]
LINK : fatal error LNK1181: cannot open input file 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\x64\Double\GTopt.lib'

The error is correct because that file does not exist in that location.

 

0 Kudos
Steve_Lionel
Honored Contributor III
7,309 Views

Would you please attach a zip of all of the .vfproj and .vcxproj files for this solution? There's a bad setting in there somewhere.

0 Kudos
Reply