Linker cannot find LIB

Question

Element.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification

2>LINK : fatal error LNK1104: cannot open file '..\Utility\C:\GS\Win32\Debug\Utility.lib'

----------------

I have a VC++ solution GS.exe with 2 Projects under it: Element and Utility. Element is dependent on Utility. After building Utility project, I built Element project. The first time was OK. But the second time onwards, I am getting a linker error, as above.  C:\GS\Win32\Debug\Utility.lib is the right location for lib, but when I build Utility project, the linker is searching a bogus directory to find Utility.lib....

Can you tell me why the first time was ok, and now I am getting this error?

Thank you.

Makoto

Answer 1

2>LINK : fatal error LNK1104: cannot open file '..\Utility\C:\GS\Win32\Debug\Utility.lib'

If that's the *actual* message (using copy & paste)
then it's obvious that the path is wrong. You can't
have a drive letter in the *middle* of a path. Fix
your properties.

- Wayne

Answer 2

I simplified my actual solution path, but I did not misspell... What you pointed out is exactly my question.

In Configuration Properties->Linker->Advanced->Import Library, I specified : 

.\$(PlatformName)\$(ConfigurationName)\$(ProjectName).lib

 My Ulility.lib was correctly generated accordingly - C:\GS\Win32\Debug\Utility.lib

What I do not understand is why Linker of Element project is searching a bogus, non-existing folder, prefixed by ..\Utility.

As I mentioned, with the same set up, the very first time I "rebuilt" the Element project, it linked ok. After that I consistently get this error.

Makoto

Answer 3

There are some confusing remarks in your posts.

>I have a VC++ solution GS.exe

*Solutions* do not have an extension of .exe -
projects may.

>when I build Utility project, the linker is searching a
>bogus directory to find Utility.lib....

When building Utility the linker is *creating* the
import lib, not looking for/reading it. The file
Utility.lib is *output* from the build of Utility,
not input to it. (You haven't stated it, but I
assume that Utility is a DLL you're creating.)

>What I do not understand is why Linker of Element project
>is searching a bogus, non-existing folder,
>prefixed by ..\Utility.

The first comment above refers to the build of Utility.
The second refers to the build of Element.

Exactly which project build *is* getting the link error?

You have shown how you specified the target name for
the import lib when it's being *created*: in
Linker->Advanced->Import Library,

How have you specified that library as *input* to the
build of the Element project? Do you have any entries
under Linker->Input->Additional Dependencies ?

- Wayne

Answer 4

I simplified my actual solution path, but I did not misspell... What you pointed out is exactly my question.
 
In Configuration Properties->Linker->Advanced->Import Library, I specified :      

You should not need to set this option (in either project). Remove it.

I would have expected that if Utility is a dependency of Element, and in the Element project you have kept the default (Yes) in Linker->Input->Link Library Dependencies, then Utility.lib would automatically be linked.

But if not, then in your Element project:

1. Set the directory for Utility.lib in Linker->General->Additional Library Directories.

2. Put the filename Utility.lib in Linker->Input->Additional Dependencies.

Correction: Above should be set Linker->General->Link Library Dependencies to Yes.

---

David Wilkinson | Visual C++ MVP

Answer 5

Thank you guys for your help.

Just to answer your question, yes, GS is my solution folder and I have 3 folders under it, GS(exe) and Element(dll) and Utility(dll).
I did mis-state my problem somewhere... Yes, rebuilding Utility is not a problem since it has no dependency. This link error happens when I try to rebuild Element project. There, the linker is seaching a bogus folder for Utility.lib.

I have been working on this same VC++ Solution/Project successfully for some time. In the past, as for Project Properties, I was using "Post Build Events" to copy all my .dlls to where my .exe is, so that I can run .exe after each build.

Now, I am reorganizing my solution folder structure to accommodate Win32/x64 & Debug/Release. I want to generate all my .dlls (and .exe) in the same directory (instead of copying as post-event). Frankly, I do not care where .libs are generated, as long as Linker can find them. Initially I generated all .libs also in the same common directory as .dlls (successfully), but Linker did not find them! even if I specified "Additional Library Directories" as such. So I ended up setting my "Import Library" as below.... and Utility.lib is created as I specified, and yet I am still having a Linker error problem.  (I guess, I do not know how to tell the Linker where to search for dependent libs.)

I am NOT trying to make a complex solution structure... ALL I am trying to achieve is to be able to rebuild project(s) after each change and hit F5 (or Ctrl F5) to run the solution within Visual Studio 2008 - without having to manually do anything. I want to set up VS to do this for Win32/x64 (Debug/Release). Also, I have more than 3 projects (I lied earlier), so I like to use "macro" such that all Project Properties are the same for all projects.

Note, I am using "Linker-Input-Additional Dependencies" only for such things as external OpenGL library, not for my own projects. If possible (and I think it is) I do not wish to hard-code all dependent libs paths for each project,

____________________
My Project Properties setup is as follows. Since I am using "macros", this setup is identical for all my projects:

Configuration Properties -> General -> Output Directory :
$(SolutionDir)\$(PlatformName)\$(ConfigurationName)

Configuration Properties -> General -> Intermediate Directory :
$(PlatformName)\$(ConfigurationName)

Configuration Properties -> Linker -> General ->  Output File :
$(OutDir)\$(ProjectName).dll

Configuration Properties -> Linker -> General ->  Additional Library Directories :
$(OutDir)

Configuration Properties -> Linker -> Input ->  Additional Dependencies : <NONE>

Configuration Properties -> Linker -> Advanced -> Import Library :
.\$(PlatformName)\$(ConfigurationName)\$(ProjectName).lib

With this setup, right now, I am getting the Linker error (shown below) when I try to rebuild Element project (after a successful Utility build). I do not know where the linker came up with this bogus search path (prefixed by "..\Utility"). 

Element.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification

2>LINK : fatal error LNK1104: cannot open file '..\Utility\C:\GS\Win32\Debug\Utility.lib'

Makoto

---

I tried removing "Import Library" above for Utility. Unexpectedly (for me), Utility.lib was also created under the same folder as Utility.dll (under C:\GS\Win32\Debug). And the same linker error during Element build.

Answer 6

Configuration Properties -> Linker -> General -> Additional Library Directories :
$(OutDir)

 Have you tried getting rid of this (in all projects) and making sure that Linker->Input->Link Library Dependencies is set to Yes?

Correction: That should be Linker->General->Link Library Dependencies

---

David Wilkinson | Visual C++ MVP

Answer 7

I do not understand which one to set to Yes. 
Do you mean Configuration Properties->Linker->Input->Ignore All Default Libraries to Yes?

Makoto

Answer 8

I do not understand which one to set to Yes. 
Do you mean Configuration Properties->Linker->Input->Ignore All Default Libraries to Yes?

No, I don't think that's the one Dave meant. More likely this:

Configuration Properties->Linker->General->Link Library Dependencies

"Link Library Dependencies"

"Gives you the choice of linking in the .lib files that
are produced by dependent projects. Typically, you will
want to link in the .lib file."

>I guess, I do not know how to tell the Linker where
>to search for dependent libs.

I would think it would be automatic *if* you have
the "Project Dependencies" and "Build Order" set
for the projects in the Solution, *and* have:

General->Link Library Dependencies

set to "Yes" under the linker properties for Element
and GS.

- Wayne

Answer 9

Thnaks for the advice...

Link Library Dependencies was Yes for all projects. I did clear additional Library Directories also.

But I am still getting the same linker error when I build Element. My question still remains the same.... Why Linker is prefixing "..\Utility\" on "c:\GS\......." to create a bogus path for Utility.lib search.

Makoto

Answer 10

I do not understand which one to set to Yes.
Do you mean Configuration Properties->Linker->Input->Ignore All Default Libraries to Yes?

Sorry, my mistake. It is Linker->General->Link Library Dependencies.
 

---

David Wilkinson | Visual C++ MVP

Answer 11

Thnaks for the advice...
 
Link Library Dependencies was Yes for all projects. I did clear additional Library Directories also.
 
But I am still getting the same linker error when I build Element. My question still remains the same.... Why Linker is prefixing "..\Utility\" on "c:\GS\......." to create a bogus path for Utility.lib search.

Do you have this path "\C:\GS\Win32\Debug" anywhere in your project? Normally, you should not because the paths in a solution are usually relative paths.
 
What is the actual relative path from the Element project directory to the location of Utility.lib?
 
Have you tried building the Release version of the project?
 

---

David Wilkinson | Visual C++ MVP

Answer 12

I tired Relase too, but the same result, so I am concentrating on Debug for now.
To answer your question, the first path below, or $(OutDir), will translates to "c:\GS\Win32\Debug".
Again, only reason I am trying to do this is to generate all my .dlls (and .exe) in here.

Configuration Properties -> General -> Output Directory :
$(SolutionDir)\$(PlatformName)\$(ConfigurationName)

Configuration Properties -> General -> Intermediate Directory :
$(PlatformName)\$(ConfigurationName)

Configuration Properties -> Linker -> General ->  Output File :
$(OutDir)\$(ProjectName).dll

As for .libs, I do not care if I put all of them in the same, single folder, or put them in the respective ProjectName folder - as long as the Linker can find them. I could say either way (see below), and lib is generated correctly, according to my specification. But either case, the linker cannot find necessary lib!

Configuration Properties -> Linker -> Advanced -> Import Library :
.\$(PlatformName)\$(ConfigurationName)\$(ProjectName).lib 
--- or---
$(OutDir)\$(ProjectName).lib

My Utility.lib is generated in :

c:\GS\Utility\Win32\Debug\Utility.lib
--- or in a single location where all dlls are also generated  ---
c:\GS\Win32\Debug\Utility.lib

My Element project is in c:\GS\Element.

Makoto

Answer 13

if option creating so much problem you simply can copy lib to your directory and then can use

#pragma comment("lib","libraryfilename")

or you can go to Tools =->options=>project Solution=>pick VC++ directory=> select show directory for library file and specify the path whr you have your library .That is another way.

Thanks

---

Rupesh Shukla

Answer 14

I tired Relase too, but the same result, so I am concentrating on Debug for now.
To answer your question, the first path below, or $(OutDir), will translates to "c:\GS\Win32\Debug".
Again, only reason I am trying to do this is to generate all my .dlls (and .exe) in here.
 
Configuration Properties -> General -> Output Directory :
$(SolutionDir)\$(PlatformName)\$(ConfigurationName)

It may not matter, but in a default vs2010 solution, these paths are written like
 
$(SolutionDir)$(Configuration)\
 
with a final backslash, and no backslashes between the items.
 
It might pay you to create a new dummy solution with two projects, and copy EXACTLY the settings you see there, and be sure that Link Library Dependencies is set to Yes. That should be all you have to do.
 

---

David Wilkinson | Visual C++ MVP

Answer 15

A couple solutions to try (these don't always work, as they use the some visual studio weirdness, but we needed to do these for a mixed native-managed project when we moved to VS2010)

1.) Make sure your project links to the other project in the Project Properties->Common Properties->Framework and References

2.) Make sure that the second project is dependent on the first in Solution Properties->Project Dependencies.

3.) Make sure wherever you put the Import Library is in the Linker->General->Additional Library Directories (In your case, if you are using a flat  file structure, ..\Utility\$(PlatformName)\$(ConfigurationName), and for the Additional Dependencies make sure to include your .lib file)

Answer 16

Thank you so much, guys, for your advice.

I will try building a dummy solution/project with one .exe and one .dll.
I am using VS2008, and it just occurred to me that a known bug of incremental linking may have something to do with this. I will disable it for test.

Again, this is all what I want to achieve:

1. In VC++, I want to change code (fix bugs), hit Rebuild, and then hit F5 (ctrl F5) to see the result.
2. To do this,I want to set up VS2008 such that I do not need to move/copy any output after each build (No Post Build Event setting even).
3. I want my project properties setup to be identical for all projects (use "macros" and no hard-coding of project names).
4. I want to do this for Win32/x64 and Debug/Release (these 4 settings should be identical).

--------------------

<Conclusion>

I created a brand new dummy solution in VS2008, and indeed, without my modifying any project properties setting, it worked exactly how I want it to work. So I set the same configuration properties setting to my exising solution/project. Alas, I received the same linker error as before. This is my conclusion...

This VC++ solution/project was initially conceived using an earlier version of VC++ (older than VS2008). When I moved to VS2008 a few years ago, it was "auto-converted" by VS2008. I think some problem was introduced at that time in my project .vcproj files. That is causing this wierd link error I am experiencing. I could compare these .vcproj files line by line (using Notepad) to see what the difference is, but it is a tedious process. Probaply it's cleaner to start a brand new solutution in VS2008, and copy all my current source code back into this new solution, now that I know all the ins & outs of configuration properties setup.

Makoto