Public Group

# Building a .lib using a .lib?

This topic is 4410 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey all, In my ongoing quest to create a game engine I've started wondering about this: suppose I have a library that employs a class for loading and rendering models in a custom file format. Is it possible to build another .lib that has been built using aforementioned .lib and and which then employs the same functionality? I am aware this may sound a bit strange (even to me :P) but let me illustrate it with a short code example:
/* In modelloader.lib */
class CModel
{
public:
Cmodel();
~Cmodel();

void SomeMethod ( void );
void Render ( void );
};

/* In the main engine library (using the modelloader.lib): */
class CEngine
{
private:
CModel *m_CModel;

public:
// Constructor, destructor, blablabla
CEngine ( void ) { m_CModel = new m_CModel(); }
~CEngine ( void )
{
if ( m_CModel ) delete m_CModel;
}

CModel* GetModelLoader ( void ) { return m_CModel; }
};


I hope this gives a better illustration of what I want. In fact, let me rephrase the question: "Suppose I use the GetModelLoader function of CEngine, will I be able to use all of CModel's methods?" Thanks in advance for any help.

##### Share on other sites
Yep, just make sure you link them in the correct order.

##### Share on other sites
Thanks for the quick answer - I have another question however. When you say "just make sure you link them in the correct order" do you mean that the 'end-user' would still have to include the modelloader.lib and take care about linking it before the main engine's library?

In other words, will the main engine library kind of 'contain' the modelloader library after it's been built or do you still need to link both .libs in all projects you'd do with the engine?

##### Share on other sites
I'm not sure on the answer to that since I've only used them in a dll setting. Hopefully someone else can enlighten us.

##### Share on other sites
Quote:
 Original post by tstrimpI'm not sure on the answer to that since I've only used them in a dll setting. Hopefully someone else can enlighten us.

If I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.

##### Share on other sites
Quote:
 Original post by SerapthIf I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.

So you can't link a static lib into another static lib the same way a static lib is linked into an executable.

##### Share on other sites
Quote:
Original post by tstrimp
Quote:
 Original post by SerapthIf I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.

So you can't link a static lib into another static lib the same way a static lib is linked into an executable.

No no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.

So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.

##### Share on other sites
Quote:
 Original post by SerapthNo no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.

That is, assuming we're talking about a .exe. In this case I'd build a library that has been linked with an already finished library. The library 'to be created' should then offer the same functionality as the already finished library without requiring the 'end user' to link both libraries...

Would this still apply?

##### Share on other sites
Quote:
Original post by rogierpennink
Quote:
 Original post by SerapthNo no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.

That is, assuming we're talking about a .exe. In this case I'd build a library that has been linked with an already finished library. The library 'to be created' should then offer the same functionality as the already finished library without requiring the 'end user' to link both libraries...

Would this still apply?

The thing is, with statically linked lib files, the "end user" is ignorant to the fact. The only case where this wouldnt be true is if you were creating a public API as a static lib file, that has dependancies on other static lib files. In this case, im not completely sure if the end user will need both lib files or not. However, if you build an EXE or DLL that link in static libraries, and distribute those, again the end user will be ignorant.

Keep in mind, you can or atleast could, statically link to the C runtime. How many other libs do you think are dependant on the c runtime? ;)

EDIT: Perhaps this will make a bit more sense. When you link to a LIB file, the linker is actually copying the code from the lib file into your project. From this point on, the origonal lib file should no longer matter. However, when linking to a dynamic library ( such as a DLL ), the linker is merely pulling in references to locations in the other library. This is why you get dependancy nightmares known as DLL hell. If those references change its not so fun.

##### Share on other sites
That sounds like it makes sense. [grin] I guess the best thing I can now do is to simply try it ;)

1. 1
2. 2
3. 3
Rutin
16
4. 4
5. 5

• 14
• 9
• 9
• 9
• 10
• ### Forum Statistics

• Total Topics
632912
• Total Posts
3009185
• ### Who's Online (See full list)

There are no registered users currently online

×