I'm still a noob in C, so I have a question about linking.
We have two programs "A" and "B", which links to the dynamic linked library "C".
Now we start program "A" and "B".
What happened now to "C". Will it be loaded once for both programs, or two times for every program?
And what is, when program B is a Python program, which make use of the foreign function interface?
It all depends on the operating system, but for e.g. Linux or Windows the shared library will only be loaded once, but it will be mapped twice. Each process using the shared library will have the library mapped, but those mappings all lead to the same single loaded library.
The mapping is done on a per-process basis, it doesn't really matter what the process does or is (if it's a program you made, a Python interpreter, or something completely different).
Searching google for Dynamic linking C gave me the following result (Shared libraries are dynamically loaded)
Shared libraries are loaded into memory by programs when they start. When a shared library is loaded properly, all programs that start later automatically use the already loaded shared library.
In the case of Windows, only the DLL (dynamic link library) code is shared between processes. Each process has it's own virtual memory address space, including the data used by a DLL. This means that a DLL normally can't have a static buffer that is shared between processes. The process or DLL code can set up shared memory, and that shared memory can be shared between processes.
MSDN articles:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681914(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.85).aspx
http://msdn.microsoft.com/en-s/library/windows/desktop/ms686958(v=vs.85).aspx
Related
I want to clear up a confusion I have regarding shared libraries. When I search online, I find in explanations to static linking that since the library is included in the executable itself, it leads to a larger executable, increasing the memory footprint of the program.
While in case of dynamic library/shared library, the library is linked at runtime. But in dynamic linking (correct me if I'm wrong), if the library is loaded into the process at runtime to be linked, does it then lead to any memory saving in any way ?
The library is loaded once into memory by the OS, and is linked to the running process by mapping its memory location into the processes virtual address space. From the processes point of view, each has its own copy of the library, but there is really only one copy in memory.
In case of a shared library between two applications, does each application use it's own copy of the library during run time ? If they use the same instance of the library, what happens to the global variables inside the library ?
It depends on the operating system. On most Unix-like systems, shared libraries use position-independent code, so the memory used by the code segment(which holds instructions and read-only variables) can be shared between processes, but each process still has its own data segment(which holds other variables).
For Unix-like operating systems, when you first execute your applications, the page tables of the two processes which map the library address space will point to the same frames in memory where the library is loaded.
However, the page tables which map the data section of the library are handled with Copy on Write mechanism. As soon as you try to write a global variable, the OS will create a process specific copy of the page containing the variable and will remap the page table of the process accordingly.
Each program creates a new instance of the library in its own memory space. They are not shared and the 2 programs will not see each other's data.
Take a look at how dynamic libraries are loaded: http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries
The same is true for statically linked libraries except instead of being loaded at runtime, they are linked at compile time.
Windows application links dynamically CRT.After the application executes part of its code it loads shared library.The shared library is linked statically with CRT.
My question is :
If the application made some changes to the "CRT state" (for example reopens stdout in some file),
will these changes be valid to in the dll code?
Thank you
No, a statically linked CRT is completely independent from a dynamically loaded CRT. The file table is different, the heaps are different, everything is different.
Assume we have a very small embedded system consisting only of the linux kernel and a single statically linked binary run as init. We want the binary to be able to dynamically load external plugins in runtime.
Is it possible on linux? Dlopen only works with shared libraries and dynamic linking cause static binaries don't export any symbols to the outside world, so is there any other way to do it?
You could run the "plugins" as child processes, and communicate over IPC (shared memory, pipes, or so forth).
They would exist in their own process space, so you couldn't directly call functions in them (besides, if they're also statically linked, you won't have any function entry points other than main that you could reach), but you could (e.g.) send a command over a named pipe, or pass data in a shared memory structure.
Note that, the moment you load the second binary, you have lost one of the main benefits of static linking (because now you have two copies of your libc loaded), so you might want to consider just biting the bullet and using dynamic linking. You'll burn a few 100K's in adding the dynamic linking support, but the GNU libc is about 2M, so if you're loading one plug-in, you've gained maybe 1.8M in savings already; and for each additional plug-in you load, you're saving some 2M.
Dlopen only works with shared libraries and dynamic linking cause static binaries don't export any symbols to the outside world
You can dlopen a shared library from a statically linked binary when using glibc. If you need your plugin to reference symbols from the main executable, you would have to pass in pointers to them into the plugin, similar to this.
is there any other way to do it?
You could also write your own module loader. The Linux kernel does this, and so does Xorg.
I have a dll which I'd like to use in a c program,
Do you think is efficient to have a dll (lots of common functions) and then create a program that will eventually use them, or have all the source code?
To include the dll, What syntax must be followed?
Do you think is efficient to have a dll (lots of common functions) and then create a program that will eventually use them,or have all the source code.
For memory and disk space, it is more efficient to use a shared library (a DLL is the Windows implementation of shared libraries), assuming that at least two programs use this component. If only one program will ever use this component, then there is no memory or disk space savings to be had.
Shared libraries can be slightly slower than statically linking the code; however, this is likely to be incredibly minor, and shared libraries carry a number of benefits that make it more than worthwhile (such as the ability to load and handle symbols dynamically, which allows for plugin-like architectures). That said, there are also some disadvantages (if you are not careful about where your DLLs live, how they are versioned, and who can update them, then you can get into DLL hell).
To include the dll, What syntax must be followed?
This depends. There are two ways that shared libraries can be used. In the first way, you tell the linker to reference the shared library, and the shared library will automatically be loaded on program startup, and you would basically reference the code like normal (include the various headers and just use the name of the symbol when you want to reference it). The second way is to dynamically load the shared library (on Windows this is done via LoadLibrary while it is done on UNIX with dlopen). This second way makes it possible to change the behavior of the program based on the presence or absence of symbols in the shared library and to inspect the available set of symbols. For the second way, you would use GetProcAddress (Windows) or dlsym (UNIX) to obtain a pointer to a function defined in the library, and you would pass around function pointers to reference the functions that were loaded.
You can put your functions into either a static library ( a .lib) which is merged into your application at compile time and is basically the same as putting the .c files in the project.
Or you can use a dll where the functions are included at run time. the advantage of a dll is that two programs which use the same functions can use the same dll (saving disk space) and you can upgrade the dll without changing the program - neither of these probably matters for you.
The dll is automatically loaded when your program runs there is nothing special you need to do to include it ( you can load a dll specifically in your code - there are sometimes special reasons to do this)
Edit - if you need to create a stub lib for an existing dll see http://support.microsoft.com/kb/131313