I am creating a gaming library, and need to find out how to export it on windows. About this, I have two questions, actually: a) I know about .dll and .lib files, but what is the main concept behind these? Is it just that the .lib is the main library, and the .dll linkes the .lib and .h file? Or how does it work? And why is it that when you include the .h file, it includes the whole library (such as in gl.h) from the .lib/.dll file? b) How do you export the files with vc++?

Quote:but what is the main concept behind these

Let's forget about dlls and libs for a moment, and look at a certain problem. You have been working on code, over the past year, that implement a number of mathematical operations. There are two new projects that could really use this code. How would those projects make use of this math project?

One option is to instruct the compiler to compile the source files in the math project as well, and then link everything together as needed. That is, you have to keep on compiling the code in the math project over and over. That's pretty awful, considering that you aren't changing the code, just using it. Why not just compile once, and store the compilation in some form that can be linked to directly?

That's what a static archive is. Compilers tend to implement some form a static archive, which is essentially code compiled into a linkable form. This static archive is compiler dependent. Visual C++ for example, uses the lib format for its archives. That's all. Remember that static archives are an issue that compilers deal with.

Now for a different question. This one is about the operating system. Building on the previous example, we consider one more question. Let's say we now have two successfully working programs that make use of the math library. But, the code is exactly the same. It's a waste of disk space, and if we run the two programs at the same time, memory. Could the operating system support some kind of binary that isn't designed to be run, but can have contained code loaded by other programs, as they desire?

This second question does have an answer. Operating systems may implement the idea of a dynamic or shared library. The idea is that a program at runtime can somehow load up this shared library and make use of the compiled code within it. To review. Static libraries are compiled code that is linked in at compile time. Dynamic libraries are binaries like executables, in that they are designed so that programs, if they wish, can take explicit steps to load the library and make use of whatever the library provides.

Consider the implications of the above. Static libraries are linked in. But you still need to compile code. So at compile time, you need to retain the appropriate headers, or you can't even compile in the first place, right? Or you can also make all the declarations manually in each file that needs them, but that's what header files are for as you know.

What about dynamic libraries? The program needs to implement code that loads in the libraries, etc. How this is done is OS implementation specific. This is always an option. In fact, if your program is designed to load libraries, without knowing what the names are. This might be the case if you some kind of plugin functionality in your program, where you can add functionality with additional libraries. In such a case, you must develop the code to the loading of the library.

But quite often, developers already know what library they want to use. So the code to load to the library, etc., is just a pain. What if the compiler could automatically take care of creating that code? And compilers do tend to implement that feature. They provide a static library that handles all the work. And so your program links in the static library, and it will then load the dynamic library without you having to write additional code. By the way, this static library is often referred to as an import library because of its purpose.

And if you were reading carefully, this import library is a static library, so it will have the same extension as a static library. Be careful with names and files if your project will have both a static library version and a dynamic library. If the dynamic library has an associated import library, you want be to able to the differentiate between the static library and the import library (which will otherwise use the same file extension).

So to answer your questions.

> Is it just that the .lib is the main library
Whether the .lib is the actual library or not depends, as I noted above, on whether it's the result of compiling as a static library, or is an import library.

> .dll linkes the .lib and .h file
Dlls aren't programs. They aren't linking anything. As I noted above, the linker will link the import library, so that your program will automatically load the the dll (or whatever the OS shared library format is).

.h files aren't linked, right? Header files only at compile time.

Quote:And why is it that when you include the .h file, it includes the whole library (such as in gl.h) from the .lib/.dll file?

Including the header file doesn't do any work on the linking portion. You still need to specify what you are linking to. If you don't have an import library, you will have to load the dynamic library yourself.

Since you are using VC++, consult MSDN and Google. Spend some time reading the details. The details don't get explained in one post.

First of all, thanks for the robust reply.



So basically, a static library is one that has the actual library (all of the function calls, classes, etc.), and an import library is one that links to a dynamically library? So, then the .h files in opengl just load the dll file in the code? But whenever I look at the source code, I don't see any linking code - just function declarations and variable definitions. How does opengl achieve this effect? libs can't be linked from the code, can they?

Sorry for the barrage of questions. I'm just making a library and want to know how to release it, and what I'm doing to release it.

Quote:Original post by MikeTacular

Quote:Original post by Phynix
But whenever I look at the source code, I don't see any linking code - just function declarations and variable definitions. How does opengl achieve this effect?

In all of my experience, I have never had OpenGL automatically linked to my program. I always have to manually add it by going to the project's linker options and adding opengl32 to the linker's list of libraries it needs to include.

What I meant by this was that opengl never links to any dll/lib fiiles inside GL/gl.h

So now, my question is tihs: how do you make a lib file?

okk, so I put my library in a lib file...now how do i link the project inside my test project? I go to linker->input then type in CGML.h, but there is no sign that the lib is included. (And yes, I copied the lib into the default lib directory, which on my computer is C:\Program Files\Microsoft SDKs\Windows\v6.1\Lib.)

When I run the program, and try to use functions that were in the lib, it says they can't be found. What's wrong?

OK, I did that, and now I get tons of errors, saying that all of the functions are already defined (e.g. 1>CGML.lib(CGML.obj) : error LNK2005: "bool leftButtonPressed" (?leftButtonPressed@@3_NA) already defined in lgjklzd.obj)

I named the cpp file lgjklzd.cpp. I just type random letters on my keyboard, since I wouldn't have to type lgjklzd anywhere. The only import I use is <code>#include "CGML.h" and #include "glutExt.h"</code>. glutExt isn't in CGML.lib, but it is required to run glut on windows (creation of the main (int, char**) function).

Could the duplicate function errors be linked to the fact that I defined all of the functions in the lib file? I thought you were supposed to do something like that...

CGML.h
void doSomething();

CGML.cpp
#include "CGML.h"
void doSomething(){
cout << "doing something"<<endl;
}

OK, it's not teh functions that are redefined - It's the variables...

do i have to extern the variables too?