I am wondering how to link third party libraries in visual studio?
the third party I mean they gave you *.dll, *.lib and *.pdb.
for example, zmq:
lib/
libzmq-v100-mt-gd-3_2_4.lib (static library)
libzmq-v100-mt-gd-3_2_4.pdb (debug file)
bin/
libzmq-v100-mt-gd-3_2_4.dll (dynamic library)
my vs project need libzmq, and I want to link zmq statically. however, I looked
at project property pages. there is no option to allow us force the program linked statically or dynamically. (perhaps, I missed something)
I set linker/general, linker/input, c_c++/general (include) to the corresponding zmq path. But, it does not work.
libzmq-v100-mt-gd-3_2_4.lib in this case is the import library rather than the full static library. Linking against libzmq-v100-mt-gd-3_2_4.lib will result in your application requiring libzmq-v100-mt-gd-3_2_4.dll.
You'll need to either build a static library from source if they don't provide one, or use it as a DLL.
Related
In a static library VC++ project, I've noticed a .lib file from another static library is listed in "Additional Dependencies".
I can't see why you would want to explicitly link one .lib into another, surely the whole point is you add libraries in the project which does all the linking into a DLL/EXE. In my case out of the dozens of libs we use, it's just this one that's added in this way. What is the reason for this functionality and when is it needed?
I'm trying to build a GUI using Qt 5.3.1 and having that link to a static lib (built with VisualStudio 2010 using /MD and /MDd). When linking in QtCreator IDE, I get 2 unresolved external linker errors generated from these two function calls from within the static lib.
Both of these (unresolved) functions are declared in WinBase.h.
::InitializeSecurityDescriptor
::SetSecurityDescriptorDacl
What is the easiest solution to get QtCreator to compile this lib? Ideally if possible, I'd like to also link whatever dependency in the static lib itself.
As the documentation of both functions specifies, you have to link against advapi32.lib. In general, all functions of the Windows SDK specify in a box at the end of the documentation the header where they are declared, the header that you should actually include and their import library.
As for the other dependencies, AFAIK there's no way to know - static libraries are just collections of object modules, that specify their dependencies only in terms of imported functions.
I am building a Visual C++ 6.0 workspace in Visual Studio 2010, so that it'll update some dependencies
I have all the files and dll's it is looking for, it builds but then fails at linking with this error
1>LINK : fatal error LNK1181: cannot open input file '\Projects\exe\CRelease/api.lib'
I have api.dll which it needs to build, but I don't have a .lib file version of it. and even if I did (like if I somehow converted the .dll into a .lib), I wouldn't know where to place it in a directory structure
how do I "fix" this?
guidance appreciated, thank you
Normally api.dll would have an accompanying import library called api.lib which is what you need to link to. The import library is different to a statically-compiled version of api (which would also likely be called api.lib) - it's more like a list of available functions provided by the dll, and so will usually be much smaller than a corresponding static library.
If you do find or get api.lib, it doesn't really matter where it lives, as long as it can be accessed by your linker.
If you don't find the import library, you're looking at doing explicit run-time linking where api.dll is loaded and unloaded explicitly in your code, and api's exported functions are called through function pointers.
I'm looking at incorporating Lua into a C++ project, and am a bit confused by the presence of the two binaries (lua51.dll and lua5.1.dll) in the distribution from Luabinaries.
According to the docs...
In Windows your library or application
must be linked with a stub library. A
stub library is a library with only
the function declarations that will
bind your DLL with the Lua DLL.
Why? I've never needed stub DLLs before when linking with third-party DLLs?
A stub library is a .lib file, not a DLL. It contains function declarations for all the exported functions in the DLL, which just forward the call into the DLL itself. So if you build an application that you want to link with lua51.dll, you tell the linker to link with lua51.lib, and all calls to exported functions will be forwarded to the DLL. If you didn't do this, you would get a lot of "unresolved external symbol" errors when linking.
This is only needed when statically linking with a DLL (so that it is loaded automatically when the application is run). It is not needed when loading the DLL dynamically with LoadLibrary.
Regarding why they have two different DLLs, The manual says this:
The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.
Basically, some existing applications link with lua5.1.dll while others link with lua51.dll and they want to support them both. In any case this is not related to the stub libraries.
I believe it's to do with __declspec(import) and __declspec(export) vs GetProcAddress. However, I don't actually know for sure.
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.