CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 3 123 LastLast
Results 1 to 15 of 37
  1. #1
    Join Date
    Aug 2000
    Posts
    1,471

    Question with .lib

    I have a question with .lib ,which might be stupid. Why would we need to link a lib file if a header file has been included? When would we need to link a lib file?

  2. #2
    Join Date
    Dec 2001
    Location
    Ontario, Canada
    Posts
    2,236
    Linking with the lib basically links with the .dll. If its a static library, linking with the lib adds the lib code to your executables code. With simply the .h file, the linker doesn't know where the function is implemented.

  3. #3
    Join Date
    Apr 2002
    Location
    PA, USA
    Posts
    1,658
    you link to the lib if you are directly linking (static linking) to the dll, as opposed to loading the dll on run time. So yes, use your .lib file even if the .h is included
    =--=--=--=--=--=--=--=--=--=--=--=--=--=
    Please rate this post to show your appreciation for those that helped you.

    Before You Post A Question, Please Read This: How & When To Ask Your Question
    =--=--=--=--=--=--=--=--=--=--=--=--=--=

    -eli
    http://www.toad-software.com
    http://www.dailymission.com - Do It Daily

  4. #4
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    The header file (.h) generally just includes the function/method prototypes. The library (.lib, .dll) is where the actual code is and thus needs to be included for the appilcation to work. Header files are used by the compiler for code generation, will the linker uses the libraries to satisfy references in the genaerated code. This is a rather simplistic view of the complie and link process...
    bytz
    --This signature left intentionally blank--

  5. #5
    Join Date
    Aug 2000
    Posts
    1,471
    Thanks for you guys' excellent comments. Now it will go to my true concern. According to your opinions, link a .lib is just a option. Am I right? However, sometimes if I failed to link a .lib, there would be linker errors. That really makes me confused. Since I have included header file, therefore at least I might link the library dynamically. Why is still there linker errors?

  6. #6
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    No, no opions here. Also no, libs are required. When you compile the code you've written is translated into machine code and stored in .obj (object files). The compiler handles one file at a time and has no knowledge of where any of the externals (functions, varialble) are or will be located, so when the compiler encounters a function, it looks in the included headers to verify the parameters, and other information. If the function is not present in the current module (file) it adds the function to a table of externals and in place of the address it would normally call it puts a place holder. The linker then takes all the obj's and libs and looks through them to satisfy all the unresolved externals and changes the placeholders to the actual address... if the lib is for a dll, the placeholder is exchanged for one that indicates that the address will be resolved at runtime.

    This is still a simple explaination, and glosses over many of the points relavite to compiler design and workings. But to stress again you need both the header and the lib; if the lib is implemented in a dll, you need the dll at runtime.
    bytz
    --This signature left intentionally blank--

  7. #7
    Join Date
    Aug 2000
    Posts
    1,471
    Originally posted by bytz
    No, no opions here. Also no, libs are required. When you compile the code you've written is translated into machine code and stored in .obj (object files). The compiler handles one file at a time and has no knowledge of where any of the externals (functions, varialble) are or will be located, so when the compiler encounters a function, it looks in the included headers to verify the parameters, and other information. If the function is not present in the current module (file) it adds the function to a table of externals and in place of the address it would normally call it puts a place holder. The linker then takes all the obj's and libs and looks through them to satisfy all the unresolved externals and changes the placeholders to the actual address... if the lib is for a dll, the placeholder is exchanged for one that indicates that the address will be resolved at runtime.

    This is still a simple explaination, and glosses over many of the points relavite to compiler design and workings. But to stress again you need both the header and the lib; if the lib is implemented in a dll, you need the dll at runtime.
    Nice explaination. However, I still couldn't understand your points one hundred percent. Let me think about it this way. If I want to STATICALLY link the libraries, what should I do?

  8. #8
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    A normal lib is always statically linked. DLL's (Dynamic Link Library) are either dynamically linked or can be loaded by the consumer at runtime. MFC exists in two forms: LIB and DLL, hence it can be either statically or dynamically linked. For MFC, I prefer static linking, as it seems to avoid problems at the cost of some space. For other libraries, it depends on how they're created, as a .lib or .dll. To add to the "confusion" .dll's always/often/mostly have a lib file which the linker uses.

    As for how to statically link the MFC libraries, use the project settings and set the MFC setting (on the general tab) to Use MFC in a static library... for other libraries, include the lib in your project or on the linker tab of the project setting, or in the off case that you're using a make file - place it in the appropiate spot.
    bytz
    --This signature left intentionally blank--

  9. #9
    Join Date
    Aug 2000
    Posts
    1,471
    Originally posted by bytz
    A normal lib is always statically linked. DLL's (Dynamic Link Library) are either dynamically linked or can be loaded by the consumer at runtime. MFC exists in two forms: LIB and DLL, hence it can be either statically or dynamically linked. For MFC, I prefer static linking, as it seems to avoid problems at the cost of some space. For other libraries, it depends on how they're created, as a .lib or .dll. To add to the "confusion" .dll's always/often/mostly have a lib file which the linker uses.

    As for how to statically link the MFC libraries, use the project settings and set the MFC setting (on the general tab) to Use MFC in a static library... for other libraries, include the lib in your project or on the linker tab of the project setting, or in the off case that you're using a make file - place it in the appropiate spot.
    Then what is the point to use dll, since no matter whether the library be statically or dynamically linked, the normal lib is always statically linked.
    One more thing unclear about that the library is statically linked. In that case, do I have to include the header files(I guess no)?

  10. #10
    Join Date
    Apr 2002
    Location
    PA, USA
    Posts
    1,658
    If statically linked, a .lib saves you the trouble of having to LoadLibrary, and GetProcAddress for all your functions and going through that frustration. You won't notice much of a difference, but take out the .lib file from your linker and watch the external errors come pouring in!

    So why use the other method? The other method isn't statically linked, you can choose to try, on the fly, to load the .dll, and if found add an extra feature, for example. The benefits of linking statically, then, are found in 3rd party development of dlls that you want to use, etc.

    There are pros/cons to both ways, but you have to decide which better fits your project. If your code won't update a lot, then no need for a .dll! If you want code to be executed from a .dll, which means it is REQUIRED to exist to run, then statically link, and as you optimize your code release newer versions of a .dll (aka sending someone a few kb instead of a whole application when you do a small update).

    Ok, I said a lot, but I'm not sure if I said anything at all

    Hope this helps though
    =--=--=--=--=--=--=--=--=--=--=--=--=--=
    Please rate this post to show your appreciation for those that helped you.

    Before You Post A Question, Please Read This: How & When To Ask Your Question
    =--=--=--=--=--=--=--=--=--=--=--=--=--=

    -eli
    http://www.toad-software.com
    http://www.dailymission.com - Do It Daily

  11. #11
    Join Date
    Dec 2001
    Location
    Ontario, Canada
    Posts
    2,236
    Yes, you always need the headers included. The lib contains different information than the headers. If you are statically linking then all of the code is contained in the lib file. If you are dynamically linking, the lib contains code which calls the code in the dll (this isn't exactly how it works, but an easy way to look at it). So there will always be some code in the lib file, so you always need the file.

  12. #12
    Join Date
    Apr 1999
    Posts
    27,449
    Originally posted by dullboy
    Then what is the point to use dll, since no matter whether the library be statically or dynamically linked, the normal lib is always statically linked.
    One more thing unclear about that the library is statically linked. In that case, do I have to include the header files(I guess no)?
    I think you are being confused with two totally different issues.

    The first issue is that is to be resolved is to make the compiler happy. To do this, the header files are needed so that the compiler doesn't give you errors that you are calling a function without a proper prototype. The linker knows nothing about header files.

    The next, totally seperate issue is linking. Once the compiler has compiled your files to OBJ files, it's job is done. The linker now steps in and creates the executable file, based on what the compiler has compiled. The linker looks at all of your function calls, and determines if these functions actually exist. The linker uses a variety of ways to do this

    a) looks to see if the actual code for the function you're calling was compiled by you.

    b) If it can't find it in the files you compiled, it then looks to see if the code exists in other libraries. If the code doesn't exist in the other specified libraries, the linker gives up and emits an error. The other libraries can be "static" or "dynamic", the former being actual object code, and the latter being just a stub to other functions located in other executable modules.

    Note that the linker that comes with VC++ can be used with any language that supports the Microsoft object format. This is why (from what I remember), the same LINK.EXE is used for VC++, MS-Fortran, and MS-COBOL programs, as well as other non-Microsoft languages.

    But in general, this is basically how compilers and linkers, regardless of the language or OS, have worked for decades.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; August 27th, 2003 at 11:11 AM.

  13. #13
    Join Date
    Aug 2000
    Posts
    1,471
    Thanks for your guys' instructions. Sadly, I am not sharp. So if I missed your points, don't get mad but just get used to it.
    I guess when the linker tries to get the actual code to implement the functions, it actually gets the addresses of functions. However for the dll, the addresses contained in it could be shared by a number of applications. However the addresses contained in the lib couldn't be shared. So here my question is what makes the addresses in the dll be shared among a number of applications? Correct me if I am wrong.

  14. #14
    Join Date
    Apr 2002
    Location
    PA, USA
    Posts
    1,658
    Take the .dll you want to view and open it up in Depends (start menu --> programs --> MS VS --> Tools --> Depends).

    Opening the dll in depends will explain a lot to you, I hope anyway! You'll see that public functions are assigned ordinals (@1, @2, etc). When you load a dll at run time, it uses the name specified before the ordinal number to look up the ordinal number and essentially find the function in the .dll.

    IIRC...
    The .lib file is pretty much doing the same. It's mapping where it's at in the dll so that when you link it can find the functions and, when statically linked, insert the function into your project.

    Take a look at it and read up on it on the internet; there are tons of articles that explain, in detail, how this stuff works and why it works.

    Go my son. We have taken you as far as we can, it is now time for you to step out into the real world.... alone.
    =--=--=--=--=--=--=--=--=--=--=--=--=--=
    Please rate this post to show your appreciation for those that helped you.

    Before You Post A Question, Please Read This: How & When To Ask Your Question
    =--=--=--=--=--=--=--=--=--=--=--=--=--=

    -eli
    http://www.toad-software.com
    http://www.dailymission.com - Do It Daily

  15. #15
    Join Date
    Aug 2000
    Posts
    1,471
    Originally posted by Eli Gassert
    Take the .dll you want to view and open it up in Depends (start menu --> programs --> MS VS --> Tools --> Depends).

    Opening the dll in depends will explain a lot to you, I hope anyway! You'll see that public functions are assigned ordinals (@1, @2, etc). When you load a dll at run time, it uses the name specified before the ordinal number to look up the ordinal number and essentially find the function in the .dll.

    IIRC...
    The .lib file is pretty much doing the same. It's mapping where it's at in the dll so that when you link it can find the functions and, when statically linked, insert the function into your project.

    Take a look at it and read up on it on the internet; there are tons of articles that explain, in detail, how this stuff works and why it works.

    Go my son. We have taken you as far as we can, it is now time for you to step out into the real world.... alone.
    Usually, I do search on the internet. But I just prefer the interactive way in the forum. There is one good thing about the discussion in the forum that we could look at the things from the different angles. That is just my humble two cents.
    Anyway, really thank you for the information. I will go get them soon.
    I wish I could be young for ever. On the other hand, am I going to be benefited a lot in my professional career if I look more senior.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured