I'm devdeloping a DLL in VS2008. When I examine the DLL in Dependency Walker, I can see a dependency on zlib1.dll. How can I find out where this comes from? My DLL is (statically) linked against HDF5.lib, HDF5_CPP.lib, and GSL.lib. I'm not including any zlib headers, so I'm a bit clueless about this. I know HDF5 depends on zlib, but I tried with the precompiled HDF5 as well as self-compiled HDF5, both to no avail.
The thing is I want to make distribution as easy as possible; that's why I link statically against all libraries I use. Funny thing is, I do link against zlib1.lib; no clue why zlib1.dll is then still a dependency.
Any ideas? Thanks!
Follow the tree within the depends tools.
The right hand tree show the "tree" of module dependency.
Click zlib1.dll in that tree and in the top right hand you will have a list of functions that are being used by the module that links to it. Search in your project to see where you are using them.
zlib1.lib is the dll lib, not the static lib for zlib. You need to obtain the and build the static lib part of the zlib distribution. I havn't built zlib... but some other projects have a xxx.lib and an xxxlib.lib, with the second form being the 'proper' static lib.
On /MT: /MT only effects the c-runtime selection: /MT adds a linker dependency to libc.lib - which statically links the c-runtime into your binary. conversely /MD adds a linker dependency to msvcrt.lib (a lib file) that contains references to msvcr90.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 have some XML parsing utility functions written inside C headers and source files based on expat library.
For this I have compiled my source files to a static library with expat statically linked to it.
I am able to use and the functions from the resulting xml utilities library with my applications only if I statically link both the utility library and expat with my application. I was of the view that I should be able to get my application built with only statically linking my utility library without requiring to statically link expat again with the application executable. Only linking my application with the utility library gives undefined symbol error for expat.
Can someone please guide me what am I missing ? I am using gcc compiler.
Thanks....
"I have compiled my source files to a static library with expat statically linked to it."
I'm fraid you haven't. A static library is not produced by the linker; no linkage is involved, so nothing can be linked to it.
A static library is nothing but a bag of object files in ar archive format.
When you are linking something that is produced by the linker - namely a program or a shared library -
you may offer such a bag to the linker. It will look in the bag and take out just the object files it needs to
carry on the linkage and link them into the target. The bag spares you the difficulty of
needing to know exactly which of the object files in it the linker will need, but the bag itself contributes nothing at all to the linkage.
Later
How can I get expat static library included in my utilities library, so that I only need to link my executable with a single static library. I don't want to extract the two archives and merge the object files together.
There is no other way of combining two ar archives.
Your resistance to linking libexpat is puzzling, without further context. It is available
through the package manager on any distro. You've made a library that depends on libexpat. Clients that link your
library will need also need to link libexpat. This is an utterly routine sort of dependency
that you should simply document and - if you are packaging your library - include
in the package dependencies. Almost invariably when we write new libraries we are augmenting the
libraries already available to our target users. If every library statically
incorporated all of its own dependencies then they would all be the size of an
operating system and of no practical use.
When I need to build some third party library to be used in several of my projects under different version of MSVC, I usually build it for every MSVC version and for both Debug and Release configurations. That's what boost does, and that's what we have been done for our whole life in my team.
However, I still don't get, why couldn't I just build this library with like... whatever. All I need is function prototype and object code, right? Since I'm linking CRT statically, I have no external dependencies. But when I'm trying to link library built in Release under MSVC8 with my project in Debug under MSVC10 I have this annoying "already defined" linker errors which we all hate so much.
But why? Can I just "encapsulate" all this functions inside lib and do not export them so that my project will take only what it needs from the lib? Why can I have precompiled version of libpng and zlib which I can link in every project? Yes, they are not build using MSVC, I guess, but the still uses the same functions of CRT. So can anyone please explain in depth or share a link to some enlightened explanation of this issue?
Since I'm linking CRT statically, I have no external dependencies
Well, that's not true, you do have a dependency. On the static version of the CRT. Debug or Release, depending on your build settings. And it is an external dependency, the linker glues the CRT later, when the library gets linked. The code that uses the library also has a dependency on the CRT. And if the compile settings don't match then the linker barfs.
You isolate that dependency by building a DLL instead of a static link library. You must further ensure that the exported functions don't cause a CRT dependency. You can't return a C++ object from the standard C++ library and can't return a pointer to an object that needs to be released by the client code. Even passing structures is tricky since their packing is an implementation detail, but you usually get away with it. A good practical example is COM automation, it forces you into using a subset of types that are universal. Windows is rife with them and all these servers work with any version of the compiler or CRT. Even any language. This however comes at a cost, writing such a library isn't as simple or convenient as just throwing a bunch of code in a static lib.
I'm trying to compile boost and mongodb.
I want 64bit versions, shared libs and dynamic linking to the runtime.
Boost is compiled with link=shared, runtime-link=shared, threading=multi (and some others). The lib and dll files have names like: boost_*-vc90-mt-1_41.dll
Now mongodb has per default set: /MT (multithreaded static). The linker required boost libraries with libboost_*-vc90-mt-s-1_41.dll (notice the additional lib and -s). So I changed the option to /MD (multithreaded dll) and the -sdissapeared but the libstayed. I tried it with /DBOOST_THREAD_USE_DLL /DBOOST_ALL_DYN_LINK but it doesn't change. Does the linker still look for the static libs?
Please help :)
BOOST_ALL_DYN_LINK should have done the trick. Please make sure you rebuild your project from scratch, though.
If the problem still persist, I guess you need to tell what is hiding behind the asterisk -- maybe there's a bug with a specific library.
I have a DLL project in VS 2008 Pro which uses OpenMP. I use /MT as 'code generation' option, because I want all my dependencies statically linked into my DLL, since I do not want to distribute many libraries to my clients - everything shall be included in this one DLL file. The problem is that my resulting DLL still depends on VCOMP90.DLL.
How can I get rid of this dependency?
Some information:
/openmp is set in compiler options
I statically link against vcomp.lib
include is set
using multithreaded library (/MT)
Thanks a lot for your help!
I don't think you'll be able to get rid of the DLL dependency - vcomp.lib is an import library for the VCOMP90.DLL - it's not a static library:
http://msdn.microsoft.com/en-us/library/0h7x01y0.aspx
It doesn't look like a static lib is provided.