Shared Library vs Static Library

[Garion]

I've been reading about libraries; How to make them, how to use them, the different types of libraries, etc..

I'm still haven't fully grasped how to implement them yet but I do have one question that the more experienced programmers here might be able to help me with.

When using a shared library, does the program require that library to be installed on the computer after the program has been compiled into an .exe?

Ie.. if somebody downloaded a "Helloworld.exe" that I had compiled on my computer using a shared library (that wasn't part of a standard operating system), would they also need that shared library on their computer for the program to run without errors?


and for Static Libraries, when I compile a program using a static library, does it include in the final binary only the functions of the library that are actually used, or does the compiler add in the entire library?

Some of my questions might not even be accurate questions but I'm still trying to understand how all this works and any help is appreciated as always :)

[LB]

Garion wrote:

When using a shared library, does the program require that library to be installed on the computer after the program has been compiled into an .exe?

That's the only reason shared libraries even exist ;)

Garion wrote:

and for Static Libraries, when I compile a program using a static library, does it include in the final binary only the functions of the library that are actually used, or does the compiler add in the entire library?

It depends entirely on the compiler, since the C++ and C standards make no mention of libraries of any kind.

[kbw]

When using a shared library, does the program require that library to be installed on the computer after the program has been compiled into an .exe?

Yes. The program (or library) has references to the symbols in the shared library. They are resolved by the program loader when it's loaded.

Additionally, shared libraries can be loaded at runtime explicitly.

and for Static Libraries, when I compile a program using a static library, does it include in the final binary only the functions of the library that are actually used, or does the compiler add in the entire library?

Sometimes.

Typically, the unit of granularity for the linker is a module; an object file resulting from compiling a single C or C++ source file.

With some special attention, some systems are able to just pull out the symbols used within a module.

It all depends on the tool set and platform.

[Garion]

Thanks for the insight kbw and LB.

I managed to make a static library and played with it some. The .exe doesn't seem to need the library anymore after the code has been compiled. I deleted the library and the .exe still works fine.

If I understood you two, by default the compiler includes the libraries object file in the binary when a program is compiled using a static library; that is unless other settings have been selected narrowing down the use of the static library's object file.

I'm going to mess with some shared libraries now to see If I can test my understanding of those.

One other question though, is the C++ standard library considered a "static library"?

[LB]

Garion wrote:

One other question though, is the C++ standard library considered a "static library"?

It depends entirely on your compiler. The C and C++ standards also allow for freestanding environments with no standard library at all (e.g. when you write code to work on a small remote control processor or something).

[Stewbond]

In a static library, the library's code is embedded into your exe. The exe gets bigger but you don't need to worry about managing versions of libraries, or sharing libraries, etc. I know that in VS, only the code you've linked to in the library gets embedded, so it doesn't bring in the entire library if you don't use it.

In a dynamic library, your library is in a file (DLL) which must accompany your exe. This is done for a few reasons:
1. Multiple applications can use the same library
2. You can update that library without recompiling the application (if a new version of some file-type comes out, just update the DLL without changing the headers and all dependent applications are auto-updated).
3. You can add extensions to pre-existing software. Microsoft Flight Simulator is a good example of this. The simulator itself is really small, but you can plug in your own DLLs and execute your own code from within MSFS. You can add your own physics models, visual models, visual rendering algorithms, virtual cockpit gauges, or even interface with custom hardware simply by dropping a DLL into the bin folder. MS just defined what your entry points need to look like.

[Garion]

DLL's or shared libraries seem like incredibly useful tools for a project.

Although DLL's seem more complicated to set up than a shared library and I think I have to use a DLL because I'm on windows.


I'm not sure I understand everything going on yet but this is what the example DLL from codeblocks looks like.

#include "main.h"

// a sample exported function
void DLL_EXPORT SomeFunction(const LPCSTR sometext)
{
    MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
}

extern "C" DLL_EXPORT BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
            // attach to process
            // return FALSE to fail DLL load
            break;

        case DLL_PROCESS_DETACH:
            // detach from process
            break;

        case DLL_THREAD_ATTACH:
            // attach to thread
            break;

        case DLL_THREAD_DETACH:
            // detach from thread
            break;
    }
    return TRUE; // succesful
}

and the example header

#ifndef __MAIN_H__
#define __MAIN_H__

#include <windows.h>

/*  To use this exported function of dll, include this header
 *  in your project.
 */

#ifdef BUILD_DLL
    #define DLL_EXPORT __declspec(dllexport)
#else
    #define DLL_EXPORT __declspec(dllimport)
#endif


#ifdef __cplusplus
extern "C"
{
#endif

void DLL_EXPORT SomeFunction(const LPCSTR sometext);

#ifdef __cplusplus
}
#endif

#endif // __MAIN_H__ 

I'm pretty sure this is the important part here, I'm just unsure of how to use this example DLL in a program.

void DLL_EXPORT SomeFunction(const LPCSTR sometext)
{
    MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
}

Could anybody provide a simple example of how to use this DLL in a program? I think what the function does is display a message with whatever string is stored in the sometext LPCSTR.

I think once i figure out these DLL's i'll start reading about making window boxes with buttons / drop down menu's but i've had a hard time finding a simple example of a DLL and a corresponding program that uses the simple DLL.

[TwilightSpectre]

DLL = Shared Library

Its just that on windows, .DLL is are the format for shared libaries, rather than .so (shared object) on unix-like systems.

Anyway, to use the DLL is really easy. When you created the DLL, your compiler should have generated a DLL file and another file as well (normally a "static library" (not really) or a .def file). If you got a .def file, you can create a library to link to that allows you to link the DLL at run time, upon loading your program. Then, you simply include the header files and call the funcs like normal.

The other method (used for when the DLL's are behaving like plugins, or you don't want to have to link to the DLL upon starting the program) is to load it at run time manually, using the LoadLibrary(ex?) functions. Once you have loaded the library, you can use getProcAddress to load the function from the DLL, based on the name provided in the .def file (which may or may not be what you called it, because of name mangling).

EDIT:
Here is a basic example of using your DLL (first method):

#include "main.h"

int main() {
    SomeFunction("Hello!");
    return 0;
}

Just link it the .a file that Code::Blocks would have generated.

[Garion]

Thanks, it works now :D

I was a bit confused because when I compiled the DLL the first time I ended up with 3 files in the bin/debug folder and 1 object file in the obj/debug folder.

This was different from when I set up the static library which I had to link the compiler to the .a file, the linker to the .o file and then point the "search directories" to the header file.

I tried doing the same file links for the DLL (shared library) with no luck. I wasn't sure what to do with the files that Codeblocks made when compiling the DLL. Codeblocks had made a .def file, .a file, and the .dll file as well as the .o file.

The big error for me was setting up the dll vs the static library was I had linked the linker to the object file's folder (obj/debug) instead of the folder with the .dll (bin/debug).

My major confusion about fixing this was all the google examples I found must have been talking about method 2.

Thanks again!