The way I understand libraries right now (on Linux) is basically that all the functions and stuff that go in a .cpp file get compiled and put it into some directory like /usr/local/src or whatever as .o files. And then the .h files go into /usr/local/include.

So now whenever you write a program that needs that library you do #include <libname.h> and then it has all the prototypes for all the library functions and also you pass the compiler -llibname so it knows to link the library .o file that is in /usr/local/src.

So I understood that that's how the SDL libraries and OpenGL libraries worked. -lSDL_image -lSDL -lGLU -lGL and so on.

But then how come for some libraries you only do #include <iostream>? How come you don't have to send flags to the linker?

Is that the difference between static and dynamic libraries? Are SDL and OpenGL dynamic libraries so just the .h files are needed? And then when the program executes on whatever platform it tries to dynamically link with the .o files that were created from the .cpp files of the library?

And then maybe iostream is a static library or .a file?

Am I totally wrong?

There are two stages to building a library:

1. The '.cpp' files are compiled to '.o' files. These intermediate files are not included in the library distribution.
2. The .o files are collected together to form a '.a' or '.so' library file. These are typically in /usr/lib or /usr/local/lib.

As you say, when you include the '.h' files, you are typically including the prototypes for the functions you will be calling. And then you pass in the -llibname to the linker so that it knows where to find the code for those functions.

However, it is possible to define the entire function in the header, in which case the code for the function is not in a library file, but included into your own object files. Examples of this are preprocessor functions in C (#define), and template functions in C++.

The reason for this is that templated code cannot be compiled without knowing the types that are being supplied to the templates, so the code is included in the header and compiled when the application code uses it. It would be possible to compile particular instantiations of the templates and include them in the libraries, but it isn't really necessary.

There are some template libraries that make use of helper code that is included as a library, but the bulk of the code is typically still in the header files.

The distinction between static and dynamic libraries is unrelated to this. When using a static library, the components that your code uses are 'copied' (linked) into the application binary at compile time. When using a dynamic library, the components that your code uses are loaded by the application from the library binary at run time.

There are two different ways to invoke dynamic libraries, but I won't go into that detail here.

Take a look at the command ldconfig. The system maintains a cache of all the available shared libraries and their location through the directory tree, so that you don't need to explicitly pass this information to the linker. It automatically tries to retrieve them from the cache. The following command prints out the content of the current cache:
other options let you add specific and custom location to the library cache. My advice is to not play with the ldconfig command, until you exactly know what you're doing, since it can mess your system up. Right now, limit the usage of this command to the line suggested above (with -p option only).

Well right now if I need the SDL library then I pass -lSDL to the compiler as an LDFLAG. Are you telling me that if I messed with my /etc/ld.so.conf file and then ran "ldconfig" again then I could compile without passing the -lSDL flag?

How does passing -lSDL tell the compiler where to find the SDL libraries anyway? I don't understand linker flags, there is no directory information in them.

And sometimes when I install new libraries the INSTALL text file tells me to run "ldconfig" when I am done. But it doesn't tell me to alter ld.so.conf, so I suppose "make install" put new libraries in the standard directories that the compiler searches? And I guess it also put libraries in non-standard directories because I still have to pass a -lflag to the linker. (And as I said above I still don't get how LDFLAGS work, they're like magical commands to me.)

The purpose of ldconfig is

• to tell the linker where to find the libraries
• to set up symbolic links so that the library name points to the most recent version
• to create a library name cache to speed up the linking

There is nothing magical about the linker flags. The '-l' flag just takes the name, prepends "lib" to it, and searches for the '.so' file and '.a' file. You can force it to use a plain filename by '-l:', but the convention is to start the name with "lib".

Your "<iostream>" example is a special case, because it is part of the standard library (libstdc++). When you link using gcc/g++, it passes flags for the standard libraries to the linker. If you were to link directly using ld, you would have to explicitly set these flags (and include the object file with the startup code).

The linker uses a set of standard paths to look for the library. This is configurable (hence the use of ldconfig and optional path flags). The runtime link path (the rpath) can be different, which can lead to confusion when you have dynamically linked libraries. But there are conventions on where libraries are placed, so it is not usually a problem.