1
votes

I have a VC++ project in VS2005 as follows:

Setup:

  • one win 32 console exe as the start-up/entry point
  • three other DLL projects....that all compile
  • console has references to the 3 DLLs, as seen in exe\CommonProperties\References. The FullPath path of each DLL project shows path to the DLL, (ie lib1.dll) for the project lib1. The same for lib2 and lib3 projects.

  • for win32 exe: ...\Configuration Properties\"C/C++"\General\Additional Include Directories includes is SolutionFolder\Lib1. ConfigProperties\Linker\General\Additional Library Directories is also SolutionFolder\Lib1

Issue:

In Configuation Properties\Debugging\Environment\Macros\References I only see references for LIB2.DLL and LIB3.DLL, not LIB1.DLL

Compilaton:

All three DLL projects compile fine.

Link Error:

Fatal error LNK1104: cannot open file '..\debug\boostlib1.lib

**Why is linker looking for a lib file (I.e. lib1.lib) instead of lib1.dll

Is this some type of path issue? How come I do not see the reference for lib1 in Config\Props\Debugging\Environment\Macros\References?

Note:

  • I am using Boost 1_39 in lib1
  • win32 exe references lib1, lib2, lib3
  • lib3 references lib2 & lib3
  • stdafx.h in win32 exe proj has a #pragma once directive
2
Why is linker looking for a lib file (I.e. lib1.lib) instead of lib1.dll -> you answer that yourself in the problem description. Add a reference to the third DLL in the project. I.e. make sure to get the dependencies right, either by using the "dependencies" method in the solution explorer or by adding the import lib for that DLL to the linker command line.0xC0000022L
Thank you for explaining this....checked dependencies and corrected linker import lib's. Working fine now.user1140215
perhaps you should upvote and accept Hans' answer then?0xC0000022L

2 Answers

1
votes

You are getting a little lost in settings that are only appropriate to the C++/CLI compiler. In other words, managed code. If you are using boost and a win32 project then you are not using managed code and these settings are not relevant.

The native code build model requires import libraries for DLLs. A .lib file. It is a small one that just contains a list of the exports for a DLL. The linker does not otherwise have the ability to read DLLs directly. You need to use the Linker, Input, Additional Dependencies setting to tell the linker what it needs to link in addition to your own .obj files. You can either spell out the full name of the .lib or just use the short name and use the Additional Library Directories setting to help the linker find the .lib file.

Find the .lib file that was generated for your DLL first. It will be located in the same directory as the .dll. And copied to the solution's Debug directory if the project is in the same solution. If you don't see it then you forgot to export functions with __declspec(dllexport). Double-check by running Dumpbin.exe /exports on the generated DLL, it shows a list of the exported functions. And try this all out on a very small test solution first with just a single EXE and a single DLL project.

0
votes

The answer to the "why?" could be something as simple as the dependency you might have added for your main project upon the DLL projects.

In visual studio 2008 the setting can be found at: Project Dependencies and simply un-checking the DLL projects will solve the problem.

Additionally you can verify that: the path to the DLL 'Lib's are no longer included in the 'linker' command-line of your main project at: Configuration Properties > Linker > Command Line