Reputation: 37924
1. Are shared libraries and dynamic libraries the same exact thing?
windows just labels them as .dll
, and linux labels them as .so
?
2. If a shared libarary has a ton of functions that a program uses, when are those functions loaded into memory?
At the start of the program? when the particular function is actually called?
3. If I make a library like this:
#ifndef SHARED_H
#define SHARED_H
#include <iostream>
#include <string>
namespace shared
{
void Function1(void);
void Function2(void);
void Function3(void);
void Function4(void);
void Function5(void);
void Function6(void);
...
void Function99(void);
void Function100(void);
...
}
//assume none of these functions call each other
#endif
and my client program only calls one of those functions, will their be performance decrease because of all the other extra functions not used?
Not worried about compilation time.. just the actual running time
4. Is question 3's scenario different if I use a class:
#ifndef SHARED_H
#define SHARED_H
#include <iostream>
#include <string>
class Shared
{
public:
void Function1(void);
void Function2(void);
void Function3(void);
void Function4(void);
void Function5(void);
void Function6(void);
...
void Function99(void);
void Function100(void);
...
private:
protected:
};
//assume none of these functions call each other
#endif
5. I'm use to making a lot of objects(.o files), and then linking them together to make my executable.
would it be better to turn all of my objects(which are usually classes) into a .so file AND THEN link them together?
I understand that the executable will rely on the .so file, unlike the first approach where the objects can just be deleted after compilation, but what is the recommendation on this?
6. I'm a bit in the dark about the difference between -fPIC and -fpic
I've heard that -fPIC will always work and -fpic is target-dependent.
What does target dependent mean? If the library is always going to be compiled and used on the same machine, am I safe to use -fpic?
some of these questions may be trivial, but I want to be certain about the things I've read so far. I appreciate any and all responses
*If relevant: using gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
Upvotes: 3
Views: 164
Reputation: 2686
For 1st and 2nd question : In Windows Xp threads have dll's(Dynamic link libraries) as component.As a thread can be considered as light process. A process is nothing but program in Execution.(run time).I guess dll and .so are similar (there might exist variation ,not sure)
External libraries are usually provided in two forms: static libraries and shared libraries. Static libraries are the ‘.a’ files . When a program is linked against a static library, the machine code from the object files for any external functions used by the program is copied from the library into the final executable.
An executable file linked against a shared library contains only a small table of the functions it requires, instead of the complete machine code from the object files for the external functions. Before the executable file starts running, the machine code for the external functions is copied into memory from the shared library file on disk by the operating system—a process referred to as dynamic linking.Dynamic linking makes executable files smaller and saves disk space,because one copy of a library can be shared between multiple programs.
For 3rd question : since in shared library only table of functions gets loaded not the actual mnemonics of code so we are saving data unlike static library where mnemonics are loaded at compile time.Which can be inferred from above explanation.
For 5th question : I think it will be better to make them as '.so' only when you know that you are going to those functions rarely.if you are going to use those function often then make those functions containing lib as static.As fetching them at run time increases responsive time .
Upvotes: 6
Reputation: 258698
Under Win, dll's
are dynamic linked libraries, meaning they get loaded separately in memory at run-time, unlike static linked libraries (lib's
) that are embedded in your module during compilation.
Under Win, before the program starts. If it can't find a dll it needs, it will report an error message and exit. That's unless you dynamically try to call functions and not actually link against the library, via LoadLibrary
and GetProcAddress
.
No. The functions have a well-known place in memory when the library is loaded. There is only one jmp
or call
instruction per function call regardless of how many functions there are.
Also no. Most probably those functions will be represented as non-member functions that take this
as an extra parameter.
The main reason would be re-usability. If you have a functionally independent module that contains multiple object files, you might as well group them together. That way you can re-use it more easily because you'd be linking to just one library instead of multiple object files.
???
Upvotes: 2