With compiler 15 (Update 1), linker fails to recognize UNC path name in LIBPATH whereas it works with Compiler 13

[FortranFan]

Has anything changed with respect to working with UNC path names (\\server\share\file_path) in LIBPATH input to linker toward building Fortran EXE projects between Intel Fortran Compiler 13 (version 13.1.3.198) and Compiler 15 (Update 1 i.e., 15.0.1.148)?

I've a project that works fine with Visual Studio 2012 and Intel Fortran 13.1.3.198.  This project fails with Visual Studio 2012 and Intel Fortran 15.0.1.148; "LINK : fatal error LNK1181: cannot open input file 'xyz.lib'"

The issue seems to be a failure with Intel Fortran 15.0.1.148 to recognize the UNC path name used in the "Additional Library Dependencies" setting in Visual Studio under Project Configuration Properties -> Linker -> General which translates to /LIBPATH:"\\server\share\file_path" option for the linker.

Now if I add an extra backslash to the UNC path name at the beginning i.e., \\\server\share\file_path, then linker works fine with Intel Fortran 15.0.1.148.

Is this an intended and known change between the compiler versions?  I couldn't find any documentation about this.

Thanks,

[Steven_L_Intel1]

I doubt it is an intended change. Are you using the same version of the VS integration, or are you observing that when you install the 2015 product it stops working? The compiler itself has no role here.

[FortranFan]

Steve Lionel (Intel) wrote:

I doubt it is an intended change. Are you using the same version of the VS integration, or are you observing that when you install the 2015 product it stops working? The compiler itself has no role here.

Thanks Steve.

By compiler version, I did mean to refer to the Intel Fortran XE product and its integration with Visual Studio and not imply any direct aspect of the compiler tool itself on this change.

And no, it's two different VS integrations: one machine running the older Intel Fortran product and the other running the newer version, both running the same corporate version of Windows 7, same version of Visual Studio 2012, same solution and project files, and the same exact source code.  As I mentioned, one minor change of introducing the extra backslash makes it work with XE 2015.

Any insight into the root cause of the change and its ramifications will be welcome.

[Steven_L_Intel1]

Ok, thanks - I just wanted to make sure I understood the problem so I could direct the bug report to the proper developers.

[Steven_L_Intel1]

I can't reproduce this. I took a project with a UNC path (with two backslashes) for additional library directories and the 14.0 integration and built it. It successfully found the library on the UNC path. I then made a copy of this solution and opened it with VS2012 and the 15.0 integration, then did a rebuild. It also linked properly. Please attach a ZIP of the two buildlog.htm files, one from the 14.0 install and one from the 15.0 install without changing the linker property, after a build that includes the link attempt. It would also be helpful if you included the .vfproj files from both versions.

[FortranFan]

Ok, thanks Steve.  I'll work toward creating a simple reproducer since I don't have the authorization to share any of the actual project files in any manner.

[FortranFan]

Hmm.. unable to get a simple reproducer to show the issue noticed in the actual case.  I'm wondering if it has something to do with the actual project build resulting in a wrapper around the link step:

Linking...
Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"Debug\Win32\\fubar.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"\\foo\bar\lib" /MANIFEST /MANIFESTFILE:"Debug\Win32\fubar.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug\Win32\fubar.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"Debug\Win32\fubar.lib" kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib foo.lib bar.lib "Debug\Win32\foo1.obj" "Debug\Win32\foo2.obj" ".. "Debug\Win32\/fubar.res"
]
Creating command line "Link @"C:\..\Debug\Win32\RSP1.rsp""

but the simple reproducer seems to invoke the linker more directly:

Linking...
Link /OUT:"Debug\Win32\\fubar.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"\\foo\bar\lib" /NODEFAULTLIB:"libcmtd" /MANIFEST /MANIFESTFILE:"Debug\Win32\fubar.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug\Win32\fubar.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"Debug\Win32\fubar.lib" foo.lib "Debug\Win32\fubar.obj" "Debug\Win32\/fubar.res"
Link: executing 'link'

Any idea what causes a project to make use of a temporary response file (RSP1.rsp) in the link step?  Is that some setting in Visual Studio?

Thanks,

[andrew_4619]

Linking...

2	Creating temporary file "RSP1.rsp" with contents

I think that happens when the link command line gets long.

[Steven_L_Intel1]

app4619 is correct. I will try another test that uses the response file.

Can you show the error from the link?

[FortranFan]

@app4619 - thanks, the tip helps me create a reproducer.

Steve,

The use of the response file seems to be the root cause.  Attached please find two zip files: <XE 2013 - TestUNC.zip> has the case that works while <XE 2015 - TestUNC.zip> has the linker error.  Build logs are included in the zip, so you can see the full description of the error.  Please note to reproduce the error, you will need to replace the UNC path I've listed (\\foo\bar) with something meaningful in your system.

Thanks, 

[Steven_L_Intel1]

Thanks! I will check it out on Monday.

[Christopher_Watford]

Has there been any headway on this? One of our developers has recently run into this, although I'm unable to reproduce on my machine. In his case it works with three slashes as proposed.

[Steven_L_Intel1]

No, sorry. I can reproduce it, it's being worked on but I have no indication of when to expect a fix. I will update this thread when I have more info. Use the three slashes as a workaround for now.

[Steven_L_Intel1]

This actually got fixed in an update to 16.0, probably update 2, but I missed it. It is also fixed in 17.0.