Fatal Error LNK1181

Hi all,

Compiling my program produces a weird reference to a file that does not exist anywhere on my computer:

LINK : fatal error LNK1181: cannot open input file ‘Files.obj’

Does anyone face the same problem?

Thank you in advance.

This looks like a command line typo.

I am assuming it is Linux.

Can you display the link line (or the combined compile-link line)
that creates this problem?

If it is Linux, send the output dialog of the link/compile-link line with the
added switches

so we can see what is happening.

If windows, send the



Hi Dave,

Thanks for taking this matter up. I’m running on windows.

Here’s the output:


Thank you.

You captured the output but not the input to the drivers.

What you typed to compile and link is probably where the problem occurs.

What I am looking for is some place in linking where

C:\Program Files…and so on

is not contained in quotes, so “Files” is treated separately from “Program”, like it is an object file.


Are you referring to the additional options to specify the paths to search for libraries? Without them, I couldn’t get the compiler to find the required libraries.

Any way to get around it?

No, I am saying that depending on the window you are using,

C:\Program Files\PGI
should be presented as

C:“Program Files”\PGI
or quotes around the whole path, or the driver may see the space
as turning the single pathname into two command line args.

Your output has things like “-IC:\Program Files\blah\blah”

which works also.

I am guessing that the input associated with the -v outputs you sent is
the problem. Spaces in filename paths. Needs quotes in some instances.

If you send the input, we may make some progress here.


What are the input you’re referring to? Do you mean what’s in the include directories? if you are it’s as follows:

C:\Users\CEEELY\Documents\Visual Studio 2013\Projects\FullProgram0\MUMPS\include
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win\mkl_blas95_lp64.lib

I cannot simply put MUMPS\include as the errors “S0017: Unable to open include file” and “S0155: Derived type has not been derived” would fail the build

I am not asking for anything that difficult.

If you created compile.log, like this

pgfortran -c -v C:\Program Files…blah…blah >& compile.log

and then sent compile.log, I want to see the line

“pgfortran -c C:\Program Files…blah…blah”

and I need to know if you are compiling in a PGI DOS window
(with ‘C:’ in the upper left corner) or the PGI bash window, with the
PGI logo in the upper left corner.

If you are running a build script, send the build script.

Hi Dave,

Please refer to the Build Log. https://github.com/Ceeely/Debugging-Program/issues/2

do you have an email I can use for correspondence? Shall we communicate through there?

This forum doesn’t have a PM feature.

The build log gives the compiler’s response to your compile commands,
makefiles, and build scripts.

Please send the compile commands, the Makefiles, the build scripts you are using
to create the build logs. Something in there is causing the driver to
look for Files.obj rather than C:\Program Files\and…so…on…

Send those to trs@pgroup.com.

Also indicate if you are using a DOS Command window, or a bash command window.


In the build log I see the fragment

-Wl,/libpath:"“C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win”"

and I wonder if the “” \ on each end of the filename is the problem.


Hi Dave,

Sorry for not responding for awhile; I had my attention on another matter.

Back on topic: Your solution made some progress (no idea why the “”\ appears each time I reopen the program) but that seems to lead to another problem:

LINK : fatal error LNK1181: cannot open input file 'dmumps_fortran.lib'

This error of unable to open the input file keeps popping up for some reason.

I’ve already put the path to the library on the Linker -> General -> Additional Library Directories “MUMPS\lib\EMT64” (On that note, do I need the full path of C:…\MUMPS\lib\EMT64 ?" ) and have the declared aforementioned library in the Linker -> Input -> Additional Dependencies. Am I missing something?

Any suggestions?

Thank you again!

Sorry about the delay.

I can think of several reasons for the link failure, if the file exists.


  1. The linker cannot find the file. The full pathname in the link line should help this.

  2. The linker does not have permissions to open the file.

  3. The file has a .lib extension, but is not a lib format.
    Perhaps it is a 32-bit lib.

If the path to the file was not in the link line with
-L/path/to/the/file/, you need to use the full pathname.