Static library outputs, static-linked libraries and dynamic runtime libraries, what are the implications ?

Question

Hello All,

 I am little confused about how I should build my dll and my exe. Firstly, can someone tell me how the OS differentiates between static libraries and import libraries, since both have a .lib extension ?

 

Secondly, I am not sure why one of my subprograms complains of missing dll, while the other subproject does not complain when both are created as static libraries and linked to a project to form a single dll.

For example...

I have a third party software, lets call it A. I can generate A.lib(static library) or [ A.lib(import library) and A.dll ]

The functions of 'A' are used in B, which I want to create as a static library, B.lib.  At this point,  should I

1. Set configuration Type of B as 'Static linked', Runtime Library as MT, and link to A.lib(static library)  or

2. Set configuration Type of B as 'Static linked', Runtime Library as MD, and link to A.lib(static library) .

3. A.lib is very large, so does it make sense to use A.lib(import library) and then provide A.dll at the target machine ?

 

Next, I have to create a dll, 'C.dll' that uses the B. 

1. Should I have to provide A.lib (static library) in the 'Additional dependencies' ? Or would this be included in B.lib ?

2. If I perform step 3 above instead of step 2 in the previous stage, should I add a.lib(import library) to the additional dependicies of C.dll

 

Finally, I have to create D.exe that calls C.dll.

1. Should I use MD or MT ?

 

 

 

 

 

 

 

Answer 1

MulanSting wrote:

Firstly, can someone tell me how the OS differentiates between
static libraries and import libraries, since both have a .lib  extension ?

The OS doesn't know nor care about .lib files. Linker does.

Static libraries and import libraries have the same format internally.  The difference is, static libraries contain actual code for the  functions, while import libraries contain tiny stubs that just point to  corresponding functions in the DLL (this is a bit of simplification, but  the basic idea holds).

I have a third party software, lets call it A. I can generate  A.lib(static library) or [ A.lib(import library) and A.dll ]

The functions of 'A' are used in B, which I want to create as a static  library, B.lib. At this point, should I

1. Set configuration Type of B as 'Static linked', Runtime Library as  MT, and link to A.lib(static library) or

Static libraries don't get linked. When you build B.lib, you don't need  A.lib.

As to Runtime Library setting, use the same one that you plan to use for  the executable that is going to use B.lib eventually. All modules that  go into an executable should be built with the same Runtime Library  setting.

3. A.lib is very large, so does it make sense to use A.lib(import  library) and then provide A.dll at the target machine ?

Doesn't make much difference. You'll end up deploying the same amount of  code either way, whether as a single file or as two files.

Next, I have to create a dll, 'C.dll' that uses the B.

1. Should I have to provide A.lib (static library) in the 'Additional  dependencies' ? Or would this be included in B.lib ?

Yes. No.

2. If I perform step 3 above instead of step 2 in the previous stage,  should I add a.lib(import library) to the additional
dependicies of C.dll

Yes.

Finally, I have to create D.exe that calls C.dll.

1. Should I use MD or MT ?

Up to you. This choice is unrelated to anything discussed above.

---

Igor Tandetnik

Answer 2

To resolve some of the confusion in the post: =The compiler settings /MT, /MD etc specify how the compiler should include the c-runtime library and does NOT effect how your own libraries get linked.

/MT means that the linker will link in 'libcmt.lib' - a large library that includes the implementation of the c-runtime. Your exe and dlls will thus each carry their own copy of the c-runtime.

/MD means the linker will link in 'msvcrt.lib' - a small library that simply causes your exe or dll to import c-runtime functions from one of the msvcrXXX.dlls - your exe and dlls will be smaller, but will not work on a system if a copy of the msvcrXXX.dlls are not installed.

Your choice :- if you can bundle the msvcr dll's with your application - or reasonably expect them to be installed - then /MD is optimal. Also, if you new or malloc objects in one exe/dll and delete them in another, then you MUST use /MD for both dll's to ensure the c-runtime managing the heap is the same.

If distributing the c-runtime is difficult then /MT is the best option as your apps can run without having to run an installer or bundle a private copy of the "large" crt dlls.

 

 

Answer 3

Thank you, Igor.  This helped me clarify some concepts and the builds work fine now.