This question is mainly aimed at shared libraries (.so files) compiled for Linux platforms. Would the new library file automatically be loaded the next time a program depending on it is launched? If not, is there a different way to do achieve this silent, self-contained library updating?

• c++
• linux
• shared-libraries
• auto-update

Many Unix-based OS have filesystems allowing this kind of stuff if you remove and then recreate the same file. As far as Vlad Lazarenko and I know, Windows & DOS are the only OS which can NOT do that.

As long as a file is opened, it's kept until nothing needs it. When you remove it, it's not viewable in the fs, but it's still present. It works for all kind of files.

But you will probably need root rights in order to do this on a library. And you should take care about synchronisation and dependencies between multiple libraries. You can quickly run h into a situation where liba v1.0 can work only with libb v1.0 and when you auto-update liba, it will fail.

There are at least two well-known programs which are using this technique : apt and rpm.

EDIT: There's really no problem if you update your library following the remove/recreate patterns. Your old but in-use library still exists both in memory and on disk. Your OS is able to reload a part of your library on disk if necessary.

Your library is still on disk as long as all the program using it are closed. It's the case even for libc. That's why when you update your libc, you are invited to restart nearly all services using it, in order to update them to the new binary code.

And that's also the main reason why you can hot-update a linux system without restarting it for years.

If on Linux, with a good Linux file system (e.g. ext3 or ext4 or btrfs), you could update a shared library (e.g. libfoo.so) within a process and program (e.g. bar) using it (e.g. dlopen-ing that libfoo.so)

You'll have preferably

1. to rename(2) the old libfoo.so to e.g. libfoo-old.so
2. to dlopen(3) the new version of libfoo.so
3. to dlsym what you want inside it
4. to perhaps dlclose(3) the old dlopen-ed handle to the old version; you can only do that if no active call frame points into the libfoo-old.so (otherwise your program will crash when returning into such call frames).
5. to unlink(2) the libfoo-old.so if needed

(you could avoid rename and you could even unlink an active dlopen-ed library; the kernel would remove it if no further directory entry or process file descriptor points to it; I won't recommend that, e.g. to ease the debugging of potential core dumps).

A simpler, but more "leaking" alternative, is to never dlclose. In practice, a program can dlopen many dozen of thousands *.so without fear. See my old manydl.c example.

Read also about dynamic software updating.

To better understand shared libraries on Linux, read Drepper's paper How to write shared libraries

You have received some excellent answers (especially Coreen's), so I thought I'd ask a question. Do you really WANT to do this? Unless you are bug fixing, and guaranteed to not alter function signatures...it might be a better idea to bump the version number, and deploy a new version, no?