linker looks for generated lib stub in the wrong location

[Timothy_W_]

Hi

I am using Visual Studio 2015 and Intel Parallel Studio XE 2016 Composer Edition for Windows.

Because of circular dependencies, I need to build a bunch of lib stubs before the dlls are build.  The Fortran DLLs are dependent on other DLLs some are Fortran and some are C++.  When I build a Fortran DLL, lets call it foobar.dll, I give the linker the /LIBPATHS and the Additional Dependencies as *.lib.  The *.libs are all there in the correct directories.  But the DLL build fails because it looks for the libs (the c++ only libs) in the wrong place.  For example c:\windows\system32\Debug\widget.lib.  Why should it look there?  It is in $(SolutionDir)$(Configuration).  Only the C++ libs must be in c:\windows\system32\Debug not the Fortran lib stubs.  All these libs are stubs for DLLs that will be built later.

To summarize: I build foobar.dll, so it builds the dependencies widget.lib (c++) with other libs (stubs).  It is available and in the /LibPaths.  foobar.dll fails because it can't find c:\windows\system32\Debug\widget.lib.

There is no mention of c:\windows\system32\Debug as a directory in foobar.vfproj.

Thanks!

Tim

[Steven_L_Intel1]

Set the linker property General > Show Progress to Show All Progress Messages. Do a relink and then zip and attach the buildlog.htm to a reply here. Your description of the problem lacks too much information and might misstate the situation.

[Timothy_W_]

Thanks for your reply.

I have attached the BuildLog.html.zip.  

The linker step is it's own project under visual studio.  It's dependencies are the *.obj files created by another lib project.  There are many lib projects that must be run before the linker project so all the dependencies can be resolved.

/LIBPATH: c:\rewrite\Debug which is where I want it to look for all the *.libs.  But the linker does not.  It looks for some in c:\windows\system32\Debug and some in c:\rewrite.   These "missing" libs like options_cpp.lib and gcommon.lib are all C/C++ libs.  The libs that are from fortran are found by the linker correctly.

Some files are listed in the lib list in the BuildLog twice

C:\rewrite\Debug\ccomon_cpp.lib then c:\windows\system32\Debug\ccommon_cpp.lib

Is there something else that is storing the lib location for the linker to read?  Why doesn't look and find what it needs in c:\rewrite\Debug?

Thanks for your help!

Regards

Tim

[Steven_L_Intel1]

It looks here as if the DLL project has an assortment of library paths specified either as "source files" or as "Additional Dependencies". These libraries are referenced by full path, not just name, so /LIBPATH would not be used. C:\rewrite\gcommon.lib is one of these, and the linker can't find that.

If you have dependent projects then Visual Studio would look in the "output directory" of those projects, but it looks more to me as if the paths are directly specified. If this doesn't help you resolve the issue, please zip the .sln and .vfproj files and attach that zip.

[Timothy_W_]

Thanks Steve.  I found the problem.  Somehow in my C++ projects, the vcxproj would set the $(OutDir) then unset it.  Since Visual Studio uses $(OutDir) to find dependencies for a project, this is a problem.  $(OutDir) was either empty or set to $(SolutionDir).  So the Fortran DLL projects could not find the dependent lib files.

I reset the $(OutDir) to $(SolutionDir)$(Configuration)\ for all configurations for the C++ projects.  That somehow correctly set $(OutDir) so when I looked at the Librarian Output directory, the macros were resolving correctly.  It could have been a few more things I fiddled with but I think setting $(OutDir) correctly with the trailing slash did it.

Regards

Tim

[Timothy_W_]

Actually I spoke too soon.  It is not working or is very touchy.  It worked once then went back to it's old ways.  I have cleaned up the use of $(OutDir) in the C++ lib projects and I still get the dll projects looking for libs either in $(SolutionDir) or in c:\windows\system32\Debug.

I will investigate further, looking at all the logs.

Regards

Tim