🔒 Locked

Confusion: Libraries, .lib and .DLL

Started by Barking_Mad Feb 14, 2006 at 6:23 PM 4 replies 6.9k views

Original Post

Feb 14, 2006 at 6:23 PM

The Main Question: I was wondering if someone could explain to me the differences between the .lib and .DLL library files, im a little confused over their function and how i use them. I understand that they basically hold a library of functions/structures that can be reused easily (*cough*). But thats about it. Background My current dilema: Im just writing a simple program to get my feet wet with SDL, but my lack of understaning with VC++ 2003.Net and Libraries isnt helping. So im trying to pick up a bit more about what they are and stuff.


SDLTest error LNK2005: __isctype already defined in LIBCMTD.lib(isctype.obj)
SDLTest error LNK2005: _exit already defined in LIBCMTD.lib(crt0dat.obj)
SDLTest error LNK2005: _fclose already defined in LIBCMTD.lib(fclose.obj)
SDLTest error LNK2005: _strncpy already defined in LIBCMTD.lib(strncpy.obj)
SDLTest fatal error LNK1169: one or more multiply defined symbols found
SDLTest warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

I understand that the Linker error is warning me that there are duplicate function definitions, presumably because SDL re-defines some standard functions from the msvcrt.lib, which i beleive is a default .lib specified within the Dev Env? I tried to add the /NODEFAULTLIB:msvcrt.lib switch to the linker command line (presumably this would remove the duplicate definition, but it introduced more errrors), i think i did this correctly, but it didnt fix the errors. What ive done:

Dowloaded the SDL Dev Libraries ( included the source, SDL.DLL, SDL.lib and SDLmain.lib )
Extracted SDL.lib & SDLmain.lib to Drive:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib (not sure if this is the correct location, but this is where i found the openGl.lib's and they worked fine :P)
Extracted SDL.DLL to both the application root dir and my system32 folder
Added both .lib's to MSVC Project>Properties>Config>Linker>Input>Additional Dependancies
Changed the Code Generation to Multi-Threaded Debug ( as recommended elsewhere for SDL )

absolute simplicity, just want to get something working


// SDLTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "sdl.h"

using namespace std;

int main( int argc, char* argv[] )
{
	//bleh bleh

	return 0;
}

As you can tell, im still pretty confused by the whole Dev Env and program construction process, even though im happy with my progress with C++ as language, the syntax and logic in general. Any help apreciated.

blanky

Feb 14, 2006 at 10:22 PM

Now just add:

#pragma comment(lib, "sdl.lib")#pragma comment(lib, "sdlmain.lib")

libs are static, DLLs are dynamic. More than one program could use a DLL. In other words, take is as DLLs are runtime, where they are loaded while you're running the program. Libs are more like the things you need are compiled into the program.

superpig

Feb 15, 2006 at 3:09 AM

Quote:
Original post by Barking_Mad
The Main Question:
I was wondering if someone could explain to me the differences between the .lib and .DLL library files, im a little confused over their function and how i use them.

There's two types of .LIB files; "static" libraries and "import" libraries.

Static libraries are just what you say - they contain chunks of code packaged in an easily digestible format. When you use a routine from a static library, the linker basically copies it over into your executable.

Import libraries are a little different. Each one is paired with a .DLL. The DLL contains the actual code, and the import library contains a manifest of the functions you could link to with information saying "this function is in DLL xyz." When you use functions in a DLL via the import library, the linker adds information to your executable saying "this executable requires DLL xyz to run; specifically it requires functions foo(), bar(), and baz() from it." That's where 'The application could not be initialized because XYZ.DLL could not be found" dialogues come from.

You don't have to use import libraries to work with code inside a DLL - if you're going to be picking and choosing which DLLs/functions you use at runtime then you won't want to anyway. Windows provides an API for loading DLLs and getting pointers to the code inside (LoadLibrary and GetProcAddress). However, using the import library means that the linker sorts it all out for you.

Quote:
I understand that the Linker error is warning me that there are duplicate function definitions, presumably because SDL re-defines some standard functions from the msvcrt.lib, which i beleive is a default .lib specified within the Dev Env?

No, these errors are present because you are using the wrong runtime library. SDL was built against the Multithreaded DLL (or Multithreaded Debug DLL) runtime libraries, not the plain Multithreaded/Multithreaded Debug.

Barking_Mad

Feb 15, 2006 at 8:44 PM

Thanks for the reply, i see you earn your rating :) superpig.

Quote:

No, these errors are present because you are using the wrong runtime library. SDL was built against the Multithreaded DLL (or Multithreaded Debug DLL) runtime libraries, not the plain Multithreaded/Multithreaded Debug.

Im not sure i fully understand what you say here, but i'll take a deeper look into those topics.

Im still unfamiliar with "built against" wrt "Multithreaded DLL".

Ill read up on multithreading.

Cheers, BM.

CraZeE

Feb 15, 2006 at 9:12 PM

whoa~ reading up on multithreading is useful but it is overkill for your situation. Here's the breakdown as best as i can explain.

Most programs are linked to a C Runtime Library (CRT). The runtime library itself exists in a few forms:

1. Single Threaded
2. Single Threaded Debug
3. Multi Threaded
4. Multi Threaded Debug
5. Multi Threaded DLL
6. Multi Threaded DLL debug

Now, without getting to much into detail yet of each variant, here's the important news: You *must* ensure that all components in a project are all compiled using the same runtime library. So if you make an EXE project that links to a LIB file and a DLL (jsut for example), you must make sure that they're all configured to link to the same type of runtime library. In the case of bundled or 3rd party LIB/DLLs, they usually provide different variants of their libraries OR they should tell you explicitly which type their library is linked to.
To change this setting, check the project properties. Select C/CC, Code Generation -> Runtime Library dropdown.

As to what each variant does, that's a bit more complicated. The easiest to understand is the Debug/Non-debug runtimes. When you're compiling into a debug configuration, you should use the Debug runtime. Easy! Why? Coz the debug runtimes will have debug symbols and information that permit you to do your code debugging properly.

As for multi/single threaded, that I cant really explain easily. However, I can help on the Multithreaded vs Multithreaded DLL. The DLL version will generate smaller output files, but the target system must have the runtime libraries installed. Which means, if you create an installer for your app, you wanna make sure that:
1. You check that the user has the runtimes installed
2. If not, you bundle the runtime DLL with your app

Point 2 makes its a moot point to use DLLs, especially when developing on .NET 2003 and above coz their runtime files may not be the same as the defaults bundled in the OS. If you wanna avoid all this 'DLL not found' errors, then link to the standard multithreaded runtime. You get a larger file output, but chances are it'll be smaller than bundling the runtimes with your installer :)

Barking_Mad

Feb 16, 2006 at 1:09 AM

Again, thanks for the help, that clears things up for me.

EDIT:
Just to clear up for anyone reading this thread in future.

My project settings were set to use multi-threaded debug code generation, not multi-threaded debug DLL.

Setting Multi-threaded DLL (/MD) solved the linker problems.

[Edited by - Barking_Mad on February 19, 2006 3:09:37 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.