I currently created a shared library(libshared.so), which contains a variable "a", which will
be modified by shared library api. i have two applications app1 and app2. app1 is using
shared library api, which changes the value of "a". now simultaneously when app2 is running
should see the changed value.
This is against the actual usage of shared library, as separate instance of shared
library will be created for every application.
now i want to use a single instance of shared library between two app1 and app2, so that
they can see same code and data segment of shared library.
Is there any possible way to achieve this, by altering gcc linker flags
These answer to :
What happens to global and static variables in a shared library when it is dynamically linked?
C Linux: Global variable located in shared library as singleton
Would shatter your expectation from the shared library approach.
I recommend you take a look at Shared Memory and the POSIX API shmget.
One process would act as a server and create the shared memory and provide the shared memory key to the client.
Another approach would be to create a pipe to share data between the process
You could read this page to have more information about inter process communication on linux
Related
Where do the variables used in shared library gets stored. when used with an application. shared library uses same application sections(data/stack). or will they have seperate sections.
Only the section that contains the code is shared. Variables are not shared between processes.
The only way to share variables between two processes is if they both have access to a shared memory page - see mmap and MAP_SHARED. Otherwise, they're in the calling process's memory space, and out-of-reach or out-of-scope of other processes.
Static libraries: Library of object code which is linked with, and becomes part of the application.
Dynamically linked shared object libraries: The shared objects are not included into the executable component but are tied to the execution.
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
I write a loader for ELF64 programs. I now have the problem that I want to export and link existing so libraries in memory.
There are additional problems related to this. First of all here is what I know.
The so library is simply Position Independent Code that is compiled in a way that it can be just placed everywhere and run. It exports several symbols and I have a real problem to understand anything from here on.
Since starting an executable in Linux will issue a loading sequence about to load any required shared library and linking the external symbols right before the application starts.
So here are the questions:
Is it true that a so library is only loaded once despite how many programs request that library.
Is there a mechanism (linux function) I can call to load a so library on runtime other than by the loader.
Is it possible to optain the symbols (addresses) to invoke methods and relocate and bind system calls of an already loaded library. What is the API to use.
4.Can I privately load a so library? Would it result into conflicts? Is there a scenario where this is actually done?
Is it true that a so library is only loaded once despite how many
programs request that library.
The .text section only needs to load once, as it is shared among processes. The .data and .bss part is private to each process so it must be reloaded from the SO for each process that is dynamically linked to the SO.
Is there a mechanism (linux function) I can call to load a so library
on runtime other than by the loader.
The dlopen() function and related. http://linux.die.net/man/3/dlopen
Is it possible to optain the symbols (addresses) to invoke methods and
relocate and bind system calls of an already loaded library. What is
the API to use. 4.Can I privately load a so library? Would it result
into conflicts? Is there a scenario where this is actually done?
I'm not sure of what you mean by "system calls", as these are referred to the operating system, which is not a shared object (well, it is actually shared, but not in that way). To get symbol addresses and invoke functions within a loaded shared object, you can use the API exposed by the dynamic linking loader, which dlopen() belongs to.
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.
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.