DLL and Static Library Doubt

[Richard Lewis]

Consider the following background information: a) I have a static library, say A.lib b) I create a DLL, say D.dll, in which I write functions that require me to link the dll with A.lib c) I ship my dll i.e. D.dll Now comes my doubt: Do I need to ship the static library (A.lib) also along with the DLL? (I observed that when I use the dll in developing an application, the compiler gives me LNK2001 errors for all functions in the static library A.lib. Of course, all LNK2001 errors disappear if I include A.lib in the application workspace. (But that's not the idea, I guess)) Any help will be greatly appreciated.:( Richard

[Toni78]

richiehere wrote: Do I need to ship the static library (A.lib) also along with the DLL? A.lib is required by the linker, so the users don't need it, and the application that you are distributing requires only the DLL file. Therefore, the answer is no, you don't need to ship the static library. However, if you are distributing only your DLL (which is required by another programmer to develop his/her own code which places function calls to your DLL) then you need to distribute A.lib and A.h as well. // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie

[Richard Lewis]

Thanks for the reply. I was quite aware that while shipping the 'exe', I dont need to ship the lib file. My specific query was regarding shipping of the static library while shipping the dll. I thought the linker (while creating the dll) would automatically extract out the 'code' from the static library and insert it into the dll code. Therefore, not requiring the lib to be shipped alongwith the dll! Please help.:((

[Toni78]

Don't get upset richiehere.:) In the previous post I mentioned the fact that if ship your dll only, then you need to send your lib and header file as well. Yes, the linker inserts the code into the dll but the dll is used by the application. For a developer it is necessary to know the functions and the parameters to these functions. That's why the header file needs to be shipped. On the other hand, the linker needs to know where to get the code (or resolve external dependencies) so that's why you need the lib file. But, you can also load the functions from a dll by calling LoadLibrary. In that case the lib file is not required. Having the lib file is more convinient. I don't understand why you won't ship your lib file, but it is up to you to decide what you want to do. If I had a choice I would prefer to get my hands on the lib file instead of calling LoadLibrary. // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie

[Toni78]

Okay, maybe this might help you a little bit more. I just got it from MSDN. "Types of Dynamic Linking There are two methods for calling a function in a DLL: In load-time dynamic linking, a module makes explicit calls to exported DLL functions as if they were local functions. This requires you to link the module with the import library for the DLL that contains the functions. An import library supplies the system with the information needed to load the DLL and locate the exported DLL functions when the application is loaded. In run-time dynamic linking, a module uses the LoadLibrary or LoadLibraryEx function to load the DLL at run time. After the DLL is loaded, the module calls the GetProcAddress function to get the addresses of the exported DLL functions. The module calls the exported DLL functions using the function pointers returned by GetProcAddress. This eliminates the need for an import library." // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie

[Iain Clarke Warrior Programmer]

I think you've has got the wrong end of the stick, if I understand his problem correctly. A.lib is a static library used BY B.dll, and is therefore now "built-in" to the DLL. It is not the LIB file created as a consequence of creating the DLL. So he does not need to distribute A.lib under any circumstance. Unless an end user wanted to use the static library themselves, but that would be independent of any reliance on B.DLL. You are right that he would need to distribute B.LIB along with B.DLL if he wanted an end user to link to the DLL, but that is (I believe) a different question. Iain.

[Ryan Binns]

No, you don't need to distribute A.lib. The library is needed by the linker to work out how to implement the calls to functions inside the DLL. It is not needed to use D.dll, and therefore doesn't need to be distributed. Hope this helps,

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

[Toni78]

Iain Clarke wrote: You are right that he would need to distribute B.LIB along with B.DLL if he wanted an end user to link to the DLL, but that is (I believe) a different question. I covered both cases since I wasn't very sure about his question. :) // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie

[Toni78]

This is what richiehere wrote: "I was quite aware that while shipping the 'exe', I dont need to ship the lib file. My specific query was regarding shipping of the static library while shipping the dll." Therefore, I told him that the library file is needed by the linker, but a developer can also use LoadLibrary (as you know, little bit more work is required). :) // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie

[Iain Clarke Warrior Programmer]

I've posted a reply to Toni78 which you should read[^]. Iain.

[Ryan Binns]

Aaah yes, but was he shipping the library so that other developers could use it, or was it part of his application that he didn't want other people to use? ;) He didn't state this in the question. The most common situation these days is to ship a proprietary DLL as part of an application, so this is what I answered :). Your reply is perfectly valid though :)

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

[Richard Lewis]

First of all, thanks for all the 'activity' being generated on this thread! Well I agree with you Ian, that is exactly my understanding. (the understanding that A.lib **need not**be shipped when shipping B.dll. But thats not the way it is working out currently. I have done exactly that. I am conscious of the fact that the size of the dll (B.dll) swells when I statically link A.lib with it. However, when using it in an application, the MSVC compiler generates LNK2001 errors (symbol not found) for all of the functions in the static library!! (I guess you might be skeptic of some settings in my compiler; but trust me it is plain code!) Thanks for help again. (Btw,please respond to this question):confused:

[Iain Clarke Warrior Programmer]

richiehere wrote: First of all, thanks for all the 'activity' being generated on this thread! You're welcome. It beats real work (which I should be doing...) and is more satisfying than answering the "please do all my (home)work for me" questions that have been reappearing. I'll make an assumption that you have two projects in your workspace. B.DLL subproject, and C.EXE project that depends on the DLL. I would *strongly* suspect you are exposing A.LIB to to C.EXE, so it ends up linking to A.LIB too. Make sure that the exe does not include any of the headers associated with A.LIB, even implicitly. I'd bet you have a B.H file with the definitions from B.DLL that includes A.H. If B.H exposes any functions / classes that are not fully implemented in B.DLL, than C.EXE will need to link them from somewhere, or it will give errors... Its hard to be more specific without actually seeing your projects, so I'm having to be general here. Iain.