I'm making a program that uses a .so library (also being developed by me). I want to be able to update and re-deploy the .so as I develop it, without restarting the program that uses it. I've demonstrated on my system (Ubuntu 15.04) that dlopen, dlsym, and dlclose can make this happen for me, if I replace the file, close the old library, open the new version via the same file path, and reload the symbol(s) I need. But what if I want to keep the old version open too?

I imagine I could achieve this by using N different file paths for N versions of the library, though I haven't tried it yet. But I'd prefer to use the same path. I can't get this to work though. If I do like this:

  1. dlopen the old .so
  2. dlsym
  3. from outside the program, rm the .so and replace it with a newer version
  4. dlopen the .so (this time wanting to get a handle to the new version)
  5. dlsym

...then I appear to end up with two copies of the same library handle, which presumably now has to be dlclose'd twice because its reference count has been increased. And I get the old versions of things from dlsym in step 5. So dlopen is not seeing my new file. I guess its reference-counting mechanism indexes files by path or something, and not by their contents? It'd be pretty weird for it to try to recognize libraries by examining their contents, I suppose.

Can I do what I want, or do I need to just use two different file paths? It's not a big deal in this case, but I'm curious. And the dlopen man pages don't seem to specify what logic dlopen uses to decide whether the library you're opening is one that you already have open.

  • The documentation says If the same shared object is loaded again with dlopen(), the same object handle is returned. Apparently it uses the pathname as the key for this, not the inode information. – Barmar Oct 12 '15 at 20:23
  • You should version your .so properly... – vonbrand Oct 13 '15 at 1:32
  • I think it's not only using the path, on my system. I've now defeated dlopen's caching system by changing the path I give to dlopen. I create in a temporary directory a hard link to the library file, and I give that new alias path to dlopen. If the file is loaded, replaced, and then loaded again via a different path (as just described), the new functions are loaded in the way I want. If the file is loaded, NOT changed, and then loaded again via a different path, I seem to get the same old library handle from dlopen (which, though unexpected, is perfectly sensible and meets my needs). – mjwach Oct 13 '15 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.