0

I am writing a plugin system for a shell in C using dlopen and dlsym with shared objetcs.

I wonder if a function in a shared object use a global in the same object, would the variable still be available for the function when loaded with dlopen, dlsym and then dlclose?

If not, what's the way to make two function in a shared object communicate between each other after being dynamically loaded?

Thank you

Nicolas Scotto Di Perto
  • 967
  • 1
  • 8
  • 23

2 Answers2

1

Your question may depend on the nature of the shared object format and implementation. Since you tagged your question [gnu], the most likely format for you to be targeting is probably ELF, the one used by pretty much all modern Linuxes and many other flavors of Unix.

I wonder if a function in a shared object use a global in the same object, would the variable still be available for the function when loaded with dlopen, dlsym and then dlclose?

With ELF, yes, unless the dynamic linker finds a different global with the same name earlier in its search path. Note also that dlopen()ing a shared object makes its contents available in more ways than just via dlsym(). The dynamic linker treats such objects pretty much the same way that it does shared libraries that are automatically loaded with the program.

It might be worth your while to read Ulrich Drepper's description of DSOs and the dynamic linking process. It's very good, and about as easy to read as you can hope for with a subject of this complexity. (Which is quite different from saying that it's an easy read.)

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
0

When a library is loaded by a process, this library will have its own memory space, in the process space, in which will be stored its static data.

If two libraries are loaded in the same process, they share the process memory space, that's mean that a library could read data from another library.... if we know where to read...

A simple approach to solve your question would be to have functions in your plug-in loader that will be callable from your plug-ins, to:

  • create such shared object, like void PLUGIN_createFooObject();
  • get pointer on this object, like void *PLUGIN_getFooObject();
  • clean-up created data, like void PLUGIN_deleteFooObject();
Mathieu
  • 8,840
  • 7
  • 32
  • 45
  • Actually the functions that needs to communicate are inside the same DSO. The system load a bunch of functions from the DSO and some functions communicate between each other with global variables in the DSO, the plugin is the set of functions founds in the DSO. So with your answer I guess it's ok. – Nicolas Scotto Di Perto Apr 21 '16 at 20:30