Sign in to follow this  
Phynix

creating .lib files in vc++ 2008 express edition

Recommended Posts

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++?

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by Phynix
So, then the .h files in opengl just load the dll file in the code?

Not quite. They just tell the compiler "Hey, there are a bunch of functions that look like this, but I don't define them; they're defined in some other library." This makes it so the compiler knows that the code you're writing is indeed valid, and that when it sees the function glVertex3f() (or some other OpenGL function) it knows that it isn't defined in your program, but instead it is defined in some external DLL.

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.

Quote:
Original post by Phynix
libs can't be linked from the code, can they?

They can by using specific preprocessor macros and what not. You can use #pragma comment(lib, "lib_name") in MSVC. Usually you don't do this though.

Share this post


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

Share this post


Link to post
Share on other sites
You can create a new Win32 Console Application, and in the setup wizard, instead of just clicking finish, click next and select either "DLL" or "Static Library"

Share this post


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

Share this post


Link to post
Share on other sites
No, no, no. Don't put CGML.h in linker->input. You put the name of the .lib in linker->input. Then you #include the CGML.h header in whatever source files you need it. You don't have to copy the lib into the default lib directory either. In the project's linker options, there is a field that is called "Additional Input Directories" or something like that. Using that field, you can simply add the path to whatever folder the .lib lives in, rather than moving it into the default lib directory.

Share this post


Link to post
Share on other sites
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;
}

Share this post


Link to post
Share on other sites
OK, it's not teh functions that are redefined - It's the variables...

do i have to extern the variables too?

Share this post


Link to post
Share on other sites
Let's do "compiler chain 101".

In the beginning there is the source file. And the source file begat the object file via the mysteries of the compilation unit.

A C/C++ compiler takes a single source file, run the preprocessor on it (which causes #include directives to be replaced with the contents of the file you listed in the #include), then compiles it.

It outputs an "object file". This object file both imports and exports certain symbols. It exports symbols for everything it defines storage or code for -- this includes functions that it contains the bodies of, and global variables that aren't linked "static" (note: static member functions and data of classes are not linked 'static'ly -- they reused the term in a confusing way).

Object files also import symbols - in particular, they import every symbol that they use but do not define (and isn't marked as being linked staticly). So if you call a function in a .cpp file, or from a .h file contained in a .cpp file, the .cpp file's object file will end up saying "I import the symbol of that function".

Got it?

After each .cpp files is compiled, you end up with a big pile of object files. These get linked to each other. Note that linking is a technical term.

At this stage, you also link against other libraries -- the C runtime library by default, and often more. Each of these libraries list a bunch of symbols they export, and a bunch of symbols they import.

The linking stage consists of lining up each export symbol with a unique import symbol.

If two object files or libraries happen to export the same symbol, this is a linker error (unless the symbol was marked inline).

If an object file or a library imports a symbol, and nobody else exports it, this is a linker error.

...

So suppose you manage to get through that. What is output is some kind of binary. Depending on the setting of the linker, you could have exported an executable, a library, a dynamic library, one of many other things.

Often the linker when exporting a particular kind of thing expects that you define certain symbols (such as main for an executable).

Suppose you are generating an executable. And you linked in an 'import library' for open GL at link time.

Then what would be stored, in machine code, in that executable would be code that loads the dynamic open GL library at run time. This might happen when the first function is called, or might be set up to happen when the executable is first loaded from disk by the operating system.

This can fail to work, and you get a run-time dynamic linking error. This is quite distinct from a linking error at link time, and it usually means that the executable didn't know where to find the library, or the library was the wrong version, or one of many sundry other DLL-hell problems you will learn to love and cherish.

...

Ok now to delve into some of the magic stuff that various development systems give you.

In order to indicate which symbols you want to export from a library, some compiler environments allow you to 'mark up' with compiler extensions the symbols that should be exported from a given library.

Other tricks include #pragma directives that cause cpp files that #include your .h file to automatically pull in your library at link time.

These are all extensions to the standard. And sometimes they are more trouble than they are worth.

This also neglects symbol-munging, the evils of inline, extern "C", and a myraid of other topics that a good programming course would help you with. :)

...

extern is the default linking behaviour of C/C++ variables and functions.

Share this post


Link to post
Share on other sites
Thanks for replying.

But, what do you mean by importing and exporting files? An object file can import/export things? Import them from where? Export them to where?

I just want to know how to make a working lib file, and what's wrong with the code i provided two posts earlier.....

Share this post


Link to post
Share on other sites
Quote:
But, what do you mean by importing and exporting files? An object file can import/export things? Import them from where? Export them to where?

I didn't say "import and export files" as far as I could tell.

I said import and export symbols.

I was trying to explain to you how a compiler and linker works. If you want to be able to do more than 'monkey-see, monkey-do' coding (or cargo cult programming), you need to understand what is going on.

And yes, this might require you to read very carefully, and study some simple cases, in order for you to learn how to fix your problem. Practically, you don't pay me enough for me to debug your code for you. :)
Quote:
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)

See, the problem is you are probably doing something fundamentally wrong, because you have no idea what you are doing.

Quote:
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).

#include "CGML.h" isn't an import.

It is an include. You are giving the instruction to your compiler+preprocessor (please take the contents of the file CGML.h, and pretend it is right here at this point in the file where I wrote #include "CGML.h").

When you are talking about things in computer science and programming language, people use words in technical ways. The words "include", "import", "symbol" and "file" are very distinct words.

Quote:
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...

I honestly have no idea what you mean by "I defined all of the functions in the lib file" means. The lib file should be generated by your compiler.

In what way did you "define all of the functions in the lib file"?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this