So I have my solution file here, which contains 4 projects.
Project A is a library which gets compiled into a .lib.
Project B is a program which becomes an .exe.
I have set up Project A as dependency for Project B, and I included
#pragma comment(lib,"terrain.lib")
into the file in Project B which uses the library.
In spite of both projects being compiled into the same Debug / Release folder, MSVCC tells me
1>LINK : fatal error LNK1104: File "terrain.lib" could not be opened.
// <freely translated from German, could mean "not found">
This:
#pragma comment(lib,"../Debug/terrain.lib")
works, but then I have to change it for release.
Is the only valid way for this using #ifdef ?
You need to specify library path in project settings ("additional library directories" in linker settings - at least in vc2008), for both debug and release configuration. You can use macros like ${ConfigurationName} and ${SolutionDir}, so specifying paths within project should be easy enough.
Also it might be a better idea to include libraries using linker settings instead of #pragma comment.
Related
I'm trying to integrate in a pre-existing code a third part library which have been given to me with three files (.dll, .lib and .exe) plus a header file .h .
I tried the following steps:
- include the header file adding also the directory in the include directories
- add the library .lib to the linker inputs additional dependancy
- move everything to the same folder of the solution
I'm using visual studio 2017. and all the code seems to compile with no errors, but when I try to access the functions of this library I got a message saying definition not found. Unfortunately I would like to access them to use only part of code that I need not the entire function.
Do I forget something / have to do something else?
The steps for integration third-party dynamic libraries with VC++:
1) Change project configuration linker settings to dynamic runtime ( /MD )
2) Confirm platform of the third party (x86 / x64) and set accordingly in the vc++ project.
3) Include the header files. No compilation errors means that the header files are correctly included by the compiler.
4) Include the *.lib with path in the additional libraries; once correctly set, the project will build successfully. Failing this step will give you - 'symbol not found', 'definition not found', and linker errors
5) Copy dll files to your application folder, failing which the .exe will not launch. The dll files also has to conform to x86/x64 the project architecture/
I am trying to create a C++ project in Visual Studio 2013 that has CGAL and Boost (and a couple of other libraries) as dependencies. I preferably like to link to these libraries dynamically. Also, I'd like to link to the "Release" versions of these libraries for performance reasons (not the "Debug" versions).
Starting from an empty C++ project, I added the path to header files of the aforementioned libraries as shown in the image below:
Inside the linker options, I then added the directories that contain the DLL and lib files of the external libraries. (CGAL directory contains CGAL's compiled DLL files along with lib files).
At this point, I have not added a single "lib" file "Additional Dependencies" dialog:
Now something weird is going on and I cannot explain why. If I try to build the project as-is (under the "Debug" configuration), I get a LNK1104 error about the linker not being able to find CGAL-vc120-mt-gd-4.7.lib. I know that the error means I should add the lib file in "Additional Dependencies" dialog...
But wait... WHAT...?!!
How does Visual Studio know how to automatically link against this lib file?! Worse yet, how does it know it needs the "debug" version of the library? (With the gd suffix). Also, how does it know I compiled CGAL with VS2013!!??
At first, I though the project was inheriting properties from some preset property sheets somewhere in my system. But I am certain that's not the case as this behavior shows even with a project created from scratch.
My main question is, how would you force Visual Studio to link against the "Release" version of this library? (eg. CGAL-vc120-mt-4.7.lib)
Side question but related: Am I even linking against the DLL files? How can I be certain that I am in deed doing dynamic linking and not static linking?
This is probably happening due to the #pragma comment(lib) mechanism - eg see What does "#pragma comment" mean?
This is a way of the compiler emitting instructions for the linker so that it can decide between multiple versions of a library depending on the compiler version. In this case it means that it can automatically pick up the correct version of the library (debug vs release, vs2013 vs vs2015, MT vs MD, etc). When you added the explicit reference to the library in Additional Dependencies then it is now trying to look for two files.
So, to fix the problem, remove it from Additional Dependencies and let VS pick the right library. If you are getting the LNK1104 error then it suggests that either the link library path isn't set up correctly, or you don't have the CGAL library file it's looking for. You can increase the verbosity settings for the linker in the Project Options to get more detail about what's happening.
I'm using Visual Studio 2013, with the 2012 toolset and I'm trying to split an win32 executable project up into an exe that consumes a dll that contains all the program logic. The end goal is to be able to create a seperate project for unit tests that can link against the new dll.
Now the old version of the project compiles absolutely fine and uses cryptlib.lib (thanks SVN!), but once I separated it out in to a dll with the program logic and the same project settings I get the following error when I attempt to build the dll:
Error 546 error LNK1104: cannot open file 'cryptopp.lib'
I have the directory that contains cryptlib.lib in my linker settings and I'm linking against it just as I did in the previous project settings. Based on the documentation it shouldn't be trying to link against cryptopp.lib because CRYPTOPP_DEFAULT_NO_DLL is defined in the preprocessor settings.
I also tried adding the directory that contains cryptopp.lib to the VC++ directory paths and I added cryptopp.lib to my linker settings, and it still gives me the same error. I don't want to use the dll version of cryptopp, but at this point I just need the thing to work.
All the projects are using the 2012 toolsets, and all are being compiled as win32 projects so I'm not sure where to go from here.
Well I figured out what was happening, if not why. For some reason the preprocessor definitions don't seem to be getting applied. If I put CRYPTOPP_DEFAULT_NO_DLL at the top of all the include files it works as expected.
I am having issues compiling a basic openGL program on VS 2012. I get a build error upon compiltation giving me:
1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'
I followed the instructions given to me by the documentation for GLEW.
In your OpenGL project open Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies -> add glew32.lib.
Also you must include #include in your sources; For that add path to your glew folder: Project -> Properties -> Configuration Properies -> General -> VC++ Directories -> Include Directories and Library Directories;
C/C++ Tab -> General -> Additional Include Directories - Add lib folder there
I have also added the glew32.dll onto my Debug folder within my project folder along with the executable. So far I keep getting this error.
If you need any more further clarification of the steps I have done please don't hesitate to ask
In all honesty, there is no real benefit to using the DLL version of glew (short of reduced executable size, but this hardly matters on modern Windows PCs).
It is not like you can simply drop a new version of the DLL into your application and use extensions that you never used before. Likewise, bug fixes are so infrequent/unnecessary with a library that basically just parses the extension spec. files that using the DLL as a means of fixing extension loading bugs in shipped software is also not practical. Statically linking to glew (this means glew32s.lib) makes much more sense in the long run.
The static linking library is also more portable on Windows, it will work with MSVC and MinGW (whereas the DLL library only works with MSVC). Link against glew32s and put that in whatever directory you decided to use for additional library dependencies.
Here is a sample solution configuration for a project I wrote that uses glew. I have established a convention for this particular software where compile-time dependencies are stored under platform/<Subsystem>. Thus, I have glew32s.lib (32-bit) and glew64s.lib (64-bit) in ./Epsilon/platform/OpenGL/glew{32|64}s.lib
Steps to Use Classes form another project (Add header and solver linker errors)
To be able to add the header from another project, first go to "Properties > c++ > General > Additional Include Directories" and add the directory that contains the header. Now you will be able to add the header of the class from the other project, but running the project will still cause Linker Errors.
Add __declspec(dllexport) before the class you are using for the other project. This can be added in the header file of that class. This should be added right before the function or variable or class name. Now you will get a lib file. (if placed in wrong place, you can get this warning: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)
"Properties > Linker > Additional Library Directories". Specify the location of the lib file that is generated.
"Properties > Linker > Input > Additional Dependencies”: Add the name of the lib file.
This sounds like the library has been specified as a dependency, but the linker/additional search path(s) has not been set to include the directory where the library is located.
This may help.
It happened to me under this situation, I clean the solution and build it again, then many errors like LNK1104 occur.
After trying to restart IIS, I build solution successfully without LNK1104 errors. I do not know why, but restarting IIS takes much more time than normal, so I guess something is used by other IIS worker process.
Just give a shot to see if this magic happens on you.
This question is old and marked solved, but I had a similar problem symptoms with a completely different solution. So just in case anyone else stumbles in here:
It appeared that because I had 2 projects under one solution (a dll and an exe), the building order was mixed (from the output window):
1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp
and so on. By the message you copied, it appears you too have more than one project under one solution. One project was looking for the *.lib file that the other build hadn't created yet.
Solution:
Right click on "main" project -> Build Dependencies -> Project Dependencies.. -> Mark which project the main one depends on.
I tried to build log4cxx for visual 2012 and, after 4 hours of resolving errors, the build was succesful (i'm not sure :)).
As a second step I tried to create a vs project to test logging.
I used this example but it keep tell me that
mainapp.cpp(2): fatal error C1083: Cannot open include file:
'log4cxx\logger.h': No such file or directory
I already specified in the linker the path of directory debug in additional library directories and I added "log4cxx.lib" additional dependencies .
I'm confused and I don't know how to make it work
thanks in advance for your help
You also need to add the directory, where headers for log4cxx are. This is not for linking phase, but for compiler phase.
This can be done with Project Properties -> Compiler -> Preprocessor (I think, I don't have VS opened now)
You don't include .lib. This file is for linking.
You need to add to includes the directory, which contains directory log4cxx, and that (log4cxx) directory must contain logger.h!