I'm reading about shared, static, and dynamic libraries. I'm having kind of a hard time with it.

What is SDL? Is it static, shared, or dynamic?

I always thought a library would be a lot of .h and .cpp files compiled separately into .o files and then if you compiled your own program you could use the -l parameter to link the library and it was all compiled together. Now I'm not so sure.

I don't even see any SDL .cpp files in my system anywhere. All I have are lots of SDL .h files in /usr/include/SDL and I don't really understand the code in them.

I'm making a wild guess here: SDL is a shared library. SDL itself is NOT compiled into my program, therefore SDL must be on any system my program tries to run on. When I compile and link SDL all it needs is the header files to know what SDL function and objects it can use. And then on every system it uses an already compiled SDL shared library thingy somewhere.

So... where is that part of SDL? All I can find are header files.

I'm thinking the advantage of shared libraries is that someone could say update SDL on their own system and take advantage of the new features without having to download new executables with the new version of SDL compiled into them for every program that uses SDL.

So if I'm making an editor and a game engine and they both use a lot of the same .cpp and .h files that I wrote and I'm tired of updating one and then the other and I need to turn them into a library, then a shared library might be kind of a silly solution. I could just make a static library. Right? Because it's not SDL. Nobody else is ever going to use this library.

SDL is C, not C++, so of course the header files are .h.

The SDL library should be located in /usr/lib/libSDL.so (or wherever your normal libraries are).

SDL is both shared and static. Like most libraries, you can make them so they are shared libraries (.so), or static libraries (.a). Most programs link dynamically however (links against the shared library). Linking can be dynamic or static. Libraries can be shared or static. Dynamic linking links against the shared library. Static linking against the static library.

In order to link a program, the library must be present and install on the system. In order to produce a executable, a program must be both compiled and linked. The compilation process is done by only using the libraries header files, but the linking phase requires the library itself.

Also, in order to run a dynamically linked program, a version of the library that is compatible with the one used during the linking process is needed on the system. A statically linked program has no such issues.

You are also overestimating the benifits of shared libraries. You cannot make big changes to shared libraries without also recompiling the programs that link against them. The reason is that if the libraries ABI changes, it can become incompatible with the previous version that the program expects to find, so the program naturally cannot run if a incompatible version is installed.

Also, depending upon how you define 'features', your statement about library updating adding features may or may not be correct. Its true that you could make bug fixes, optimitations, and do other things that dont effect the API of the library. Care must be taken, however, not to alter the ABI.

Also, using static linking in a single project, you remove any benifit of using a library. You cannot update the library seperatly, because each executable embeds the library within it. Meaning that using a static library would require you to recompile the entire project anyways to take advantage of alterations in the static library. Using a shared library would be more benifitial, but then you must take ABI compatibility issues into account.

Thanks. I still wonder if static library might make sense for me though. Look at my situation. I am making two programs, game editor, and game engine. They both use several of the same .cpp and .h files. Suppose they both use animate.h and animate.cpp

/home/icecube/project5/src/animate.cpp
/home/icecube/pr5edit/src/animate.cpp

Now suppose I alter animate.cpp in pr5edit. Now I have to remember to overwrite animate.cpp in project 5. Very annoying.

So instead I have a separate folder with all shared files in it.

/home/icecube/icelibrary/animate.cpp
/home/icecube/icelibrary/animate.h

and in all .h files I change
#include "animate.h"
to
#include "/home/icecube/icelibrary/animate.h"

This method works for now but I don't think it is very professional. I think I should turn all those shared files into a library. And I think turning them into a static library would be fundamentally the same as what I'm doing now. But I suppose I could make them a dynamic library.

The reason I haven't done it yet is because I don't know how to do it in KDevelop. I suppose I can make my own makefile and compile the library myself. But I wonder if I lose all the extra stuff the IDE put into the configure.in file? I don't really understand the IDE configure.in file, it is very big and does lots of mysterious things. I think I would rather compile my library in the IDE if I knew how.

Weird. You seem to be doing things the hard way.

Game editor and game engine, seperate programs: yes, seperate projects: no. They are both the same project. So why you seperated them I do not know. Normally, one would place those programs in the same directory, sharing small 'libraries' of code. During compile, the 'libraries' are compiled as objects. Then the actual programs are compiled, using the object files produced earlier.

There is no need to create a real library, either static or dynamic. Just use normal object files. (compilier option '-c').

Or another (slower way) to compile such a project: compile each program seperatly by passing the source files needed. No need to store the related code in a outside place, or to copy such files.

I dont use KDE, and I dont use IDEs, and I never used KDevelop, so I have no idea how to accomplish this in such a IDE. However, I do know that this is a basic method used to compile projects, and only the only projects that dont do it are really small programs with only a few source files. Even makefiles are done in such a way that encourages one of the above approuches over splitting the same files into diffrent places.

Also, you are aware that the '-I' compiler option is used to give include file directories? There is no need no use #include "/home/icecube/icelibrary/animate.h", just pass the compiler -I/home/icecube/icelibrary/. Or was the option '-i'? Eh, one of them. Maybe the option is called something like 'include directories' in your IDE?

Yeah there's a lot of stuff I don't know.

So one makefile should be creating two programs?

I don't really see what the difference would be. Two projects with a shared library vs. one project compiled into two programs. Probably you're right, I just don't get it yet.

Yeah I guess you're right. I think I figured out how to do what you are saying in an IDE. I think I should put all my .h and .cpp files that I had for two separate projects and put them into the same project. And then in the IDE I think I just pick "add target" in order to make two different executables. Or if I'm wrong I'm sure it's something like that. I think I can figure it out.

Any 2nd opinions out there?

Yes, I think that's a good idea. You can have multiple targets in one project. For each target you can specify which source files you want to compile. You can put your animate.cpp in both, so that when you change it, both targets will link with the new animate.cpp (you have to recompile both, of course). This is actually like static linking, you are placing the cpp code right into the output executable.

If you want to change the shared code without recompiling both projects, you can create a shared library: you first compile for example animate.cpp separately in a shared library like animate.so. In the projects that use the library you would just need to include the animate.h file and specify your library in the linker flags (-l or -L). After that you can recompile the library without having to recompile the projects the use it. Of course, like SciYro said, you are not allowed to change the API. So the way you use functions have to stay the same.

For your project I would recommend using two targets.

Regards,
Christian