I am having a lot of trouble with static libraries and DLLs, and I can't seem to find any real help anywhere online. If someone could please help me out here, I would greatly appreciate it. Here is the situation: I have E.exe that links to a number of static libraries (say, L1.lib, L2.lib, L3.lib). Moreover, E.exe loads a DLL (D.dll), that would like to use the objects in each .lib. However, some objects in the .libs only have their functions defined in their .cpp files. For instance, L1.lib Object1.h void Ob1Func(void); Object1.cpp void Object1::Ob1Func(void) { ... } Now, to complicate things a bit more, L3.lib has an object inherits from an object in another .lib. That is, L3.lib Object3.h #include "Object1.h" Object3 : public Object1 { } So, when I try to create an Object3 in my DLL and call a function in Object1 that is defined in Object1.cpp, I get a linking error (LNK2019 - unresolved external symbol). Now, all I include in the .dll is a header file that includes each object's .h file for the objects in the .libs. So, E.exe E.h #include "Object1.h" // from L1.lib #include "Object2.h" // from L2.lib #include "Object3.h" // from L3.lib D.dll D.h #include "E.h" To me, this should all work fine; however, it clearly doesn't. Object3's created in D.dll cannot access their Object1 functions -- and I cannot figure out why. Any ideas? Is there something that I am missing with whole .lib .dll thing? (I guess you might keep in mind that I have not created my own .libs and .dlls before). Thanks for any help.

Well yeah, that's what it seems like; however, I thought I was.

Does including E.h in D.h, when E.h includes objects from each .lib, not take care of the linking? If it doesn't, how do I go about linking the actual .lib with the dll? I am using MSDE v7.0, and have including a path to the .lib files in the dll's properties (under Linker->Additional Library Directories), but is there something else that I have to do?

Thanks for your help.

Quote:Original post by liquidsharp
Well yeah, that's what it seems like; however, I thought I was.

Does including E.h in D.h, when E.h includes objects from each .lib, not take care of the linking? If it doesn't, how do I go about linking the actual .lib with the dll? I am using MSDE v7.0, and have including a path to the .lib files in the dll's properties (under Linker->Additional Library Directories), but is there something else that I have to do?

Thanks for your help.

No, it doesn't, you have to provide the linker the static libraries as well, do that by adding the names of the libraries on the project properties->linker->input->Additional Dependencies spot, provided you have added the path like you described.

Hmmm, for some reason I was thinking that the linker would go to the Additional Library Directories and check those libraries for the functions it needs to link. I guess it kind of make sense that it doesn't.

So, my next question is this: Can I make a library of libraries, say E.lib that includes L1.lib, L2.lib, and L3.lib, so that I can just include this one library in D.dll, and not the whole list of them?


Also, I included the additional libraries, like Kwizatz suggested, and these are some of the linking errors I get:

LNK2005: "public: __thiscall std::_Lockit::_Lockit(int)" () already defined in L1.lib(Object1.obj)

LNK2005: "public: void __thiscall std::_Mutex::_Lock(void)" () already defined in L1.lib(Object1.obj)

LNK4006: "public: __thiscall std::_Lockit::_Lockit(int)" () already defined in L1.lib(Object1.obj); second definition ignored

LNK4006: "public: void __thiscall std::_Mutex::_Lock(void)" () already defined in L1.lib(Object1.obj); second definition ignored


Now, I was thinking that because D.dll is including L1.lib, and E.exe is including L1.lib, we are running into a conflict (similar to not putting #ifndef, #define, ..., #endif around classes and then including them again and again). But, then I thought that things probably don't work like that with a library. Especially when you use Win32 in almost everything, and there are no problems when you include one library in another library, and they both include Win32. So, any ideas?


And thanks again for your help. I have tried asking for help in forums before, and people rarely reply. This forum has certainly been helpful.

Quote:Original post by liquidsharp
Now, I was thinking that because D.dll is including L1.lib, and E.exe is including L1.lib, we are running into a conflict (similar to not putting #ifndef, #define, ..., #endif around classes and then including them again and again). But, then I thought that things probably don't work like that with a library. Especially when you use Win32 in almost everything, and there are no problems when you include one library in another library, and they both include Win32. So, any ideas?

Nope, your first hunch is correct, when you link against a static library, you copy over the functions (symbols) indistinctively whether its an exe or a dll (exes and dlls are structurally the same thing), when you link against a DLL you just copy the reference to the functions.

Since both your executable and your dll are including the same static library, you have a conflict, you have to decide where do you want the static lib to reside, either in the exe or the dll, probably the DLL.

And no, you can't group static libraries together, though you could extract the object files from all of them and then group all of those in a single static library.

Edit: you could also NOT export the functions that reside in the static library from the dll.

You know, I figured there was an issue with including the same static libraries in both the .exe and the .dll, but when I took them out of only one of them, I was still getting errors. But, then I realized that I had set certain libraries as dependencies of other libraries (set within the IDE), so I removed those dependencies and that seemed to clear everthing up. Now, so far anyway, everything seems to be working like I have been trying to get it to. So thanks Kwizatz for all your help.

I went ahead and extracted all of the object files and put them into a single file that I include in the .dll, and that seems to be working too.

So until the next hitch, thanks.