• Advertisement
Sign in to follow this  

Building a .lib using a .lib?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by tstrimp
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Serapth
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.


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

Share this post


Link to post
Share on other sites
Quote:
Original post by tstrimp
Quote:
Original post by Serapth
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Serapth
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by rogierpennink
Quote:
Original post by Serapth
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Serapth
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.


This is the case. The end user isn't the person using the final application but the programmer implimenting the derived library.

Share this post


Link to post
Share on other sites
Quote:
Original post by tstrimp
Quote:
Original post by Serapth
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.


This is the case. The end user isn't the person using the final application but the programmer implimenting the derived library.


Im not talking implimenting though, im talking if the person wants someone down the road to be able to compile against their code. Even then it shouldnt matter. For example, if I create 4 libs, one for adding, one for multiplying, one for division and one for subtraction. Then later on down the road, I want to create an uber math lib that links in all methods from those 4 libs I can. The only catch I can think of is the linker will only link in code that is referenced. So, in the case of my math lib, I didnt link in a certain function for my add.lib, that function will no longer be available to people I distributed math.lib to.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement