Hello everyone,

I am looking into dynamic loading using dlopen to actually load the same .so file but having different data section (globals & static vars) regions for each of the loads.

From what I can understand from dlopen manpage:
"If the same library is loaded again with dlopen(), the same file handle is returned. The dl library maintains reference counts for library handles, so a dynamic library is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. The _init routine, if present, is only called once. But a subsequent call with RTLD_NOW may force symbol resolution for a library earlier loaded with RTLD_LAZY."

How can I avoid this behaviour of dlopen. Is there any other function such as dlopen that is not as restrictive ?
Will I have to implement my own dlopen if I want to achieve that ?

Please comment.
Thanks in advance for you help

This is indeed the normal (and only) behaviour of dynamic loading. I can't recall any other library offering such a functionality.

You could work around it by e.g. programmatically making individual uniquely renamed copies of the original *.so and linking those dynamically. This way each instance will keep its own static data.

Hi fantas and thanks for the reply.

Sure, although not a very efficient implementation, and in my case, out of question.
Do you think it would be possible using dlinfo to access internal structures that dlopen uses and just change the name of the .so (in those structures) such that in the next load it actually reloads again ?

Once again, thanks a lot.

I ran into this problem a few years ago when developing a plug-in system for an application of mine. Essentially the application would load the specified plug-ins (with dlopen) and pass them parameters specified in a configuration file (via a dlsymmed function.) For example, one might load a plug-in to filter IP addresses of incoming socket connections, and it's perfectly reasonable to want to load it more than once using different parameters. The problem I had was that the static data contained in the library was exactly the same no matter how many times it was loaded; there was always only one instance associated with the process that loaded it.

I'm not sure if you have an initialization function you manually call (e.g. to pass parameters,) but if you do, consider having the process that loads it pass a unique reference for each load instance. For example, the solution to my problem was to add an argument to the initialization function (e.g. load_plugin(int instance, const char *options)) and reference that in subsequent calls to functions within the library (e.g. check_address(int instance, uint32_t address).) This, of course, requires that you have control over the library's API. Internally, the libraries use a hash table to locate the context data for the specific load instance. Even though the library is loaded only once, enumerating the load instances allows you to "fake" multiple instances internally.

Loading a library only once is one of the most useful things about shared libraries. In fact, on many systems the library is only loaded once system-wide; only the data is process-unique. Imagine if your program linked to 5 libraries that were linked to libm; you wouldn't want libm loaded 5 times when your program runs.
Kevin Barry

PS The functions shown in red would be a part of the library's API.