I am working on a c++ project that links to a static library. However, I want to use intel's TBB, which is only available as a dynamic library. I tried to set this up in visual studio but I can't get it to work. Does anyone have detailed directions to do this if it is possible?
Typically when a library is made available as a dynamic library (.dll), it also comes with a .lib file to link against (as discussed in this question). This can be added to the project's list of inputs the same way that a static library is
Project Properties->Configuration Properties->Linker->Input->Additional Dependencies (in VS2008)
If a .lib is not available, then you'll have to load the .dll at runtime using Win32 API function LoadLibraryEx and then subsequent calls to GetProcAddress to get the addresses of the functions you need.
Are you talking about linking to a RUNTIME library? No you can only link to one. You have to either change your project, or you have to recompile the TBB to link to static runtime as well.
Related
I've knowledge of C++ and compiling small plug-ins (always based on a similar and laid out workflow). Though currently I need to compile the latest version of FFTW into a static library (or get it from the compiled version which should supposedly be a lot easier) and it's giving me an insanely hard time. Probably because I don't know the ins and outs of compiling. As a note I'm working on Windows with Visual Studio.
Since I really want to know how this should work I'm asking the question here.
Basically I need a static .lib of fftw3f library on Windows that I can include in another Visual Studio project.
The first I did was download the 64 bit dll's of FFTW from the website (hoping I could use this).
http://www.fftw.org/install/windows.html
Then I've done the accompanying step they stated, that is:
Run the following in lib.exe.
lib /def:libfftw3-3.def
lib /def:libfftw3f-3.def
lib /def:libfftw3l-3.def
I've done this as well and got a .lib file that I could use in my project correctly. I've been able to compile my project, yet the output build apparently dynamically linked to the library instead of including it as a static library.
I'm compiling my project to .dll but require the fftw3f library to be statically included in my output.
Using lib.exe /list libfftw3f-3.lib I was able to find out that the lib file was referencing the libfftw3f-3.dll.
According to my google results this would mean the .lib file that I created is a DLL import library instead of static library.
It's hard to figure out how to phrase my question because I'm not sure what the terminology is and what's going on behind the scenes. I guess:
How can I use the libfftw3f-3.lib file created from lib.exe as a static library in my own project. So that it is included in my output .dll instead of dynamically linked?
Based on what I learn from comments/answers I'll be happy to update/edit/rephrase my question to make more sense for most other users as I'm likely way of with the terminology
You cannot expect to convert a DLL into a static library.
In order to create a static library you need to re-compile the library from its source code, with an output target that is a static library. If you cannot obtain the source code, then your goal cannot be achieved.
This question is regarding dynamic linking of libraries and usage of dynamic linking of libraries in application.
For example we are devloping an application using C++ using Visual studio environment.
Here for include header files we specify in Additional Include Directories, and
in Additional Dependencies: Mylibrary.lib
in Additional Libraries Directories: We specifies path of libraries
And in Windows we also have "LoadLibrary" API which is used to load dynamically linked ibrary.
My question is
when we include dll in Additional dependencies libraries why we should use "LoadLibrary" API?
When we should use "LoadLibrary" API?
Thanks!
LoadLibrary lets you continue program execution if the dll is not on the running machine. It returns an error status that can be checked and execution can be continued.
Also, linking lets you do stuff like use classes from the other binary & others. LoadLibrary only lets you find functions via GetProcAddress.
Imagine that you have a software that for example needes at a determined time to convert
Internet network address into strings.
On windows vista or later you can use the "InetNtop" function that is also able to deal with ipv6, but if you link directly to the DLL your program will no work on lower OS (ex: windows xp).
So the best solution would probably be making 2 DLL's one that used "InetNtop" and another that used for example "inet_ntoa".
Then your "main" program would do at runtime a LoadLibrary of the "InetNtop DLL", or the "inet_ntoa DLL", according to the OS that he his installed.
You asked that you can include dll in Additional dependencies libraries, and then why to use loadlibrary.
First lets clear the understanding:
While linking statically, A programmer is needed to add the .lib file to
Additional library dependency, which is linked to the caller program at compile time,
However, Dlls are loaded dynamically, hence you need not to add dlls in Additional library dependency when you are using LoadLibrary ie; if you are linking the Dll explicitly you are not needed to give your dll path in Additional library dependencies.
Please note:
using LoadLibrary you will be able to Get the Dll handle, which you can call the exported function using GetProcAddress.
refer:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
A library i'd like to use makes calls to functions like "malloc_dbg" which are defined in libcmtd.lib but not in libcmt.lib (so I get Linker errors in Release mode)
Do I really need to use the debugversion of that lib even in releasemode? or can I somehow use libcmt.lib and libcmtd.lib together, but use libcmtd.lib only for this other library and use the releaseversion for the rest of my application?
Thanks!
Maybe you can implement malloc_dbg yourself and call malloc from there?
But this is just a workaround. The lib you are using should provide you a release version without these calls!
Since your question is
c++ What to do if Library makes use of debug version of other library?
Here's my advice, in this order:
Don't use this library. -- If the library doesn't even provide a proper release version, then it isn't fit for anything.
If you must, and as in your case it appears that the lib requires the static debug version of the runtime lib, then try to create a wrapper around this library so that your project can compile with proper settings.
Compile your project with the debug libraries. If you link statically to the runtime libraries, then you wont have a problem with redistribution and for small stuff it may be acceptable to use this approach.
Since you write in the comment you have this problem with GLUI I assume the fault is with you, not with the library. GLUI is an open source project, so you should be able to compile the lib (even an old version) with the appropriate settings for your environment.
I have a framework (in C++) which is dependent on a few third party libraries. When I compile a static version of the library framework, no additional dependencies are needed, that is, the lib files of the third part libraries are not needed. When I compile the same framework as a DLL, additional dependencies are now needed otherwise I get linking errors. I can guess as to why this is happening but would like a concrete answer/explanation to understand what is happening.
EDIT: Just to clarify, I am developing a framework which can be compiled as a lib and as a dll and then used in a(n) (executable) project. When compiling the framework as a lib and using functions from a third party library, I don't need additional dependencies. However, a project that now uses the lib file (which is the framework) must include the 3rd party lib files. When I compile the framework as a dll it gives me linking errors unless I specify the 3rd part libraries the framework is technically dependent on. For example: I have a few classes that call functionality from within Ogre3D. These classes are compiled as a lib file. I don't need to link against OgreMain.lib when compiling a lib of the classes. On the other hand, when I am compiling a dll version of the same classes, I now need to link against OgreMain.lib
When you have a static library (a .lib file), which is just a collection of one or more object files (.obj), the linker just adds that code to yours in one executable. You can tell the linker to do this via a command line switch, an IDE configuration setting, or perhaps even a #pragma (specifics depend on your environment and compiler).
When you link in a DLL, you need to give the linker some code to call when you invoke one of the DLLs functions. Usually, this is done with a file of the same name as the .dll, save that it is a .lib. The code in that .lib is linked into your program the same way as described above, but when you call it, it loads the DLL (if not already loaded) and then invokes the proper function.
There are other ways to handle DLL linking (for instance, .def files or #using statements in .NET), but this seems to be what you're talking about.
Responding to your question clarification:
The issue is that a .lib is not a final product. It is just an aggregation of object code to be used later when a linker connects all your functions calls to function addresses.
A DLL, on the other hand, is a final product, and so the linker requires all functions and variables be connected to actual addresses.
I'm speaking a bit imprecisely, but you get the idea.
A static library can include other static libraries, providing a single lib to link
A DLL can include static libraries, providing a single DLL to link.
A DLL or static library with dependencies on other DLLs has no way to combine them so your executable must explicitly link to those other DLLs.
When you link to a LIB it adds all the symbols/functions you actually use to your executable. The ones you don't use won't get added. When you link to a dll - all the code from the external library gets loaded. If this additional code (code you don't use) depends on more external libraries you need to provide these as well.
One example: You want to use a ip class from a network library. The ip class does not depend on other libraries. Other functions in the network library depend on other external libraries. If you link the network library as a LIB you just link the ip class -> you don't need the other libraries since the other code wont get linked. When you use the DLL all code in the dll need to be instanciated -> so you will need to provide the other external libraries.
Building a DLL is more like building an application than a library. The difference between building an application and a DLL is knowledge of what might be called. In an application all symbols that are not used can be discarded in the build, but in a DLL you cannot strip symbols that are not used - that would be all of them...
You would find the same link problems in your static libraries if you where able to call all the symbols that the DLL links.
Why do some C++ projects require a runtime package to be installed, while others do not?
EDIT:How to make a project to work without the runtime?
Some will have been statically linked, while others will depend on a dynamic library, loaded at run-time. To link your own project statically, you need to change your project configuration - how you do this depends on the compiler/linker and/or IDE you are using.
Some applications are built linking with the system libraries this are the dynamic linked programs.
Other programs contains the code of the libraries into the executable file this are the static linked programs.
Pros of dynamic linked:
Smaller size of the program executable.
Less memory consumption if the dynamically linked library is shared.
Better performance.
Cons of dynamic linked:
Dependency on the library.
Deployment is more dificult.
Pros of static linked:
No dependencies.
Easier deployment of the application.
Cons of static linked:
The executable file is bigger.
To get a static project you need to set up the option in the project properties.
I think this refers to the VS2005 service pack 1 runtime. For some reason MS added some non-backward compatible features to it, so any app built with VS2005sp1 requires the runtime to go with it.
You need to have runtime package installed in case you are working with standard C/C++ library linked as DLL, and not as static library. So one way to avoid it is to link standard C/C++ library statically (C++ project settings). It may, or may not be possible in your case.
If not, you can use dependency walker tool from Visual Studio distribution to identify the DLLs needed by your application and just put them near your executable.
What you should be aware in Visual Studio 2005 and later is that there are the manifests for binaries can (and probably will :) make your life harder. Specially since SP1 for Visual Studio 2005 changes the version of C++ library, and the manifests as well.