Can an automatic update of a Linux C / C ++ shared library overwrite its own file on disk to a newer version?

This question is mainly for shared libraries (.so files) compiled for Linux platforms. Will the new library file be loaded the next time the program is loaded, depending on how it starts? If not, is there any other way to achieve this silent offline library update?

+3


source to share


3 answers


Many Unix-based operating systems have file systems that allow this look if you delete and then recreate the same file. As far as I know Vlad Lazarenko, Windows and DOS are the only OS that CANNOT do this.

As long as the file is open, it is saved until nothing is needed. When you remove it, it doesn't show up in fs, but it's still there. It works for all types of files.

But you will probably need root privileges to do this in the library. And you have to watch out for synchronization and dependencies between multiple libraries. You can quickly run h in a situation where liba v1.0 can only work with libb v1.0 and when you automatically update liba it will not work.

There are at least two well-known programs that use this method: apt and rpm.



EDIT . No problem if you update your library after remove / rereate templates. Your old but used library still exists in both memory and disk. Your OS can reload part of your library on disk if necessary.

Your library is still on disk while all the program it uses is closed. This is the case even for libc. So when you update your libc, you are prompted to restart almost all services using it to update them to the new binary.

And this is also the main reason why you can quickly update a Linux system without restarting it for years.

+6


source


If in Linux with good Linux filesystem (like ext3 or ext4 or btrfs) you can update the shared library (like libfoo.so

) in process and program (like bar

) using it (like dlopen

-ing what libfoo.so

)

Preferably

  • to rename (2) old libfoo.so

    , eg.libfoo-old.so

  • dlopen (3) new versionlibfoo.so

  • to dlsym

    what you want inside it
  • possibly dlclose (3) the old dlopen

    -ed handle of the old version; you can only do this if libfoo-old.so

    there is no active call frame in the window (otherwise your program will crash when returning to such call frames).
  • to unlink (2) libfoo-old.so

    if necessary


(you could avoid rename

, and you could even the unlink

active dlopen

-ed library ; the kernel would remove it if no additional directory entry or process file descriptor points to it; I won't recommend this, for example, to make it easier to debug potential dumps core

).

A simpler, but more "leaky" alternative is never dlclose

. In practice, a program can be dlopen

many tens of thousands *.so

without fear. Check out my old example manydl.c .

+3


source


You got great answers (especially Coreen's), so I decided to ask a question. Are you sure you want to do this? If you don't fix the bug and make sure you don't change the function signatures ... maybe it's better to consider jotting out a version number and deploying a new version, right?

0


source







All Articles