I thought this should be straightforward but I am running into a bunch of linker errors like so:
Error 1 error LNK1104: cannot open file '...\Debug\Utils.lib' ...\LINK
where Utils is one of the C++ projects I want to keep as DLL.
If I change Configuration Properties->Configuration Type to Static Library(.lib) everything compiles and runs fine, but if I use .dll then its not working.
The whole solution is native C++ with the main project being a win32 console application.
Perhaps your library (Utils.lib) is not assembled as DLL and changes in console application project (that uses library) will not help.
Read carefully MSDN to see features of DLL's creation and usage.
It you try to link a .lib against another .lib, it doesn't really link. Instead, this instructs the final link to use both libraries.
For a DLL, this can't work, as the runtime linker cannot link the original .LIB. That means the link has to happen when the DLL is compiled.
As a result, a DLL project needs to have the .LIB directories set right.
Related
I have some confusion about static and dynamic linked libraries and .lib and .dll files.
I have a project with two libraries, one I built myself and one is from an open source library.
The one I built myself is a separate project in the same solution (Visual Studio 2015, C++), and I don't need to copy over the .lib files or create a DLL for the executable to build and run
For the other open source library, I do need to copy over the .lib file and the DLL into the executable folder. However, I thought it would be possible to statically link a .lib file and not have to copy over the DLL.
Does this mean I need to compile the Open Source library differently? Like change the define __declspec(dllexport) to __declspec(dllimport) ? Or change /mD to /mT in compiler options?
I tried both of these, but it's still saying that it can't start without the .dll
Or can I get away with changing a setting in the executable project to link this library statically? If so, what are these settings?
EDIT: I know this is a standard question that can be looked up on google, but I haven't been able to find an exact answer for a while. Mainly, I'm confused about what settings need to be changed, and which project they need to be changed in. (The library or the executable).
I'm under assumption that static linking means the library is built into the executable, and dynamic linking means the library needs to be in a separate file, if this is incorrect, please let me know. Otherwise, I need to know how to build the library into the executable file.
And I can go ahead and change the build options in the open source library, and I tried this already.
Thanks,
-D
In Windows, dll files (dynamically linked libraries) need to be in the same directory as the application or on the search path. lib files (static libraries) need to be statically linked during linking (the last step of building the application). It's common in Windows so have a library come with both a dll and lib file. In this case, the lib file is an import library containing the information needed to easily link to the dll.
Place the dll file where your application will be built and statically link with the lib file. Go to 'Project->Properties->Link->Input->Additional Dependencies' and 'Project->Properties->Link->General->Additional Library Directories' to specify the static libraries you want to link.
Edit: It seems I misunderstood the question. The question is how to recompile a dynamic library as a static library. You need the source code of the library you are using along with it's Visual Studio Project file. Open the library and in `Project->Properties->General->Configuration Type' change it from Dynamic Library to Static Library.
Beware that Dynamic Library uses the Linker group of properties while the Static Library uses the Librarian group of properties. Changing between these types may cause the project to drop essential linker flags options. Since every library is different, I can't predict what you will have to do work around this. Make sure to backup the project file so you can see the original options and flags.
I had to change the setting for "Static Library" for All Configurations, not just Debug, although it was building in Debug. Not sure what may have caused this. Possibly because the debug and release builds for the library were set to the same folder, it may have been overwriting the debug builds with release builds when building
I have a project that works great.
I created a new and independent .dll project that contains the origin project with some exported functions (copied the origin .h and .cpp files to the new project). I copied from the origin project all the lib dependencies and paths to those libs and additional include files. its the same setup.
The new program compiles but the problem is that when I try to run the code, I get that error msg:
The program can't start because xxx.dll is missing from your computer. Try reinstalling the program to fix this problem.
that xxx.lib is on the Additional dependencies list and its not the first one:
Additional Dependencies: aaa.lib; bbb.lib; ccc.lib; xxx.lib, zzz.lib
I guess that VS found the first three .lib otherwise I would get some error message.. so why can't it find xxx.lib? all the .lib files in the same folder..
thanks.
You appear to be misreading the error message. It says:
The program can't start because xxx.dll is missing from your computer. Try reinstalling the program to fix this problem.
Note that it says xxx.dll is missing, not xxx.lib!
On Windows, a LIB file is often used as an aid to the linker when using a DLL. The LIB contains import stubs for functions provided by the DLL. You need the LIB file when you build the binary; you don't need the LIB file on the machine to run the resulting binary. However, you do need the DLL!
The reason that this might be confusing is that, if you are going to statically link an object file, you only need the LIB. It contains all of the code, and there is no DLL required. But this is not the strategy you are using. The linker is using the xxx.lib file to arrange for the EXE to be dynamically linked to xxx.dll. Thus, the EXE requires the DLL to be present in order for it to run.
Copy xxx.dll into the same folder as your EXE, and then launch the application again. This has nothing to do with your compiler/linker/build settings.
I've created a Static Library (no mfc is used in it) in Visual Studio and want to link with it in statically linked mfc project (com-dll actually).
When linking mfc-lib I get a bunch of messages symbol is already defined. This is because I linked standard C++ library twice (once in static library, and other in mfc project).
How do I fix it?
There is a workaround with /FORCE:MULTIPLE, but I think this is a bad decision.
When linking static libraries to a DLL or EXE project, you need to take care, that all projects have been compiled to use the same runtime library. So please set all projects to the same "Use of MFC" and also to the same "Runtime library". If you do not do so, then one project might have been compiled to take the fopen function from the standard CRT while another project might have been compiled to take the fopen function from the MFC. Mixing these is a problem for the linker because he does not know which runtime (and in the example: which fopen) to use.
When linking your DLL or EXE project against another DLL project, this is not a problem. You can have a DLL without MFC usage and link your MFC EXE against that DLL.
If you have a util library that you use very often in different projects, then you might consider setting up different build settings so you can build your library in DEBUG and RELEASE and with and without MFC. Then in your EXE project you can pick the library binary that matches your project settings.
I have a DLL that I compiled from source (gdal). I have a simple C++ Win32 console project that has one source file, but I want to link against that DLL. Currently, when I try to run the project, it compiles correctly, but says that it cannot find the DLL. If I move the DLL to the same directory as the DLL, the exe will run. Is there a way to make my output EXE include the DLL so that I can just move one file to another system and run it without having to send the DLL with the exe.
How can I make this happen in VS2010?
Unless you had the original source code for the .dll, recompiled as a static library (.lib) and then statically linked to it, I don't believe there's a way to "include" the dynamically linked library inside your executable.
You need the DLL in the path, or in the current directory for your application to run. That is how it works with DLLs.
With static libraries, the linking embeds the library code into your application. If you cannot or do not want to have the DLL available, you could change your DLL to a static library.
Since you are compiling it from source you can just add the source files to your project and build it right into your executable.
You could create a Post-Build Event in the Visual Studio project that runs a script to copy the DLL to the path of the executable.
Then, when you deploy your application, an installer would be able to take care of the DLL management for you.
I have a dll and an exe, both of which I have the sources to.
For the DLL I have compiled completely statically and therefore, I would assume that the the .lib is also static. However, when I include that lib in my C++ VC++ 2008 project under Linker > Input > Additional Dependencies . I set the compile mode to /MT (multi-threaded) for the exe.
Everything compiles, but when I try to run the exe, it asks for the dll! To the best of my (limited) understanding, that shouldn't be happening.
Why should I do?
The 'compile mode' setting that you are referring to is the setting for the runtime library that gets linked with whatever library or executable you produce.
If your project is set up to produce a DLL (check the main project page), then it'll still produce a DLL no matter what you're putting into the runtime library setting. What I think you want to do is change the setting on the DLL's main project page from DLL to Static Library instead of changing the runtime library setting.
Once you've done this, make sure that both the executable and library projects have the same runtime library setting (the /MT switch you refer to), otherwise you'll get tons of strange error messages if the linker is trying to match up two different runtime libraries in the same executable.
The .lib file that is created with a "static" DLL is just an import library that handles automatic dynamic linking to all the symbols in the library. The DLL itself (that is, the .dll file) still contains all the code/symbols/etc. that you expect.
Statically linking to the .lib file just saves you from manually calling LoadLibrary()/GetProcAddress(), etc. to resolve symbols within the DLL.
You'll still need the DLL itself unless you build a true static library (that is, with all the symbols & code, rather than just the imports).