KPIC makes programs running crash when libraries are recompiled

Question

Hi,
I have a very simple library that wraps a Timer class and a test program linked to it.
First of all, I compile the library and the main without the KPIC flag. Then, I execute the program and, while it's running, I add some dummy sentence to the library and recompile it. Nothing happens to the binary running. It keep unaware of changes in the library and keeps running.
Now, I recompile everything with KPIC and try to make the same test. Just when the library has been recompiled, execution is broken by a core dump.
You'd say that it has an easy solution: do not use the KPIC but I'm trying to develop my program in 64 bits and I'm forced - as far as I know - to compile using the KPIC flag.
Any idea of how to make it work? I can't assume to stop all my programs after any change in the library.
Thanks in advance
Jorge Ortiz

Answer 1

Let me clear up a few points and add to what amorrowcrcg has said.
Whether you are building a 32-bit or 64-bit program is a separate concern from generating PIC (positiion-independent code). PIC means that the code contains no absolute addresses. All references are relative to the program counter or the starting address of a section, or to a table in a shared library.
Code that goes into a shared library should be compiled as PIC. Otherwise, the library is cannot actually be shared; each process that links to it gets a separate copy.
Since PIC is often a little larger and a little slower than ordinary code, there is no reason to generate PIC except for use in a shared library.
You cannot overwrite a shared library while a process is using it. As previously explained, the file is truncated to zero size, then grows to its full size as data is copied into the file.
In many cases, you can replace a shared library on the fly by first removing it, then copying a new version into the same location.
% rm destdir/mylib.so
% cp srcdir/mylib.so destdir
When you remove the file, you really are just removing the entry in the directory that points to the file. The file itself is not removed until there are no more references to it. Any processes currently using the shared library still have access to it. When the last such process exits, the OS sees that the file has no more references, and removes the file.
When you copy in a new version of the library, processes started after the copy is complete find the library via the directory entry, which now points to the new library version. If a process starts before the copying is complete, the process can fail when it finds an incomplete library. (The copying might be suspended while a new process starts.)
A better technique is copy the file to a temp in the destination directory, then rename the temp:
% cp srcdir/mylib.so destdir/mylib.so.tmp
% rm destdir/mylib.so
% mv destdir/mylib.so.tmp destdir/mylib.so
You now have a time period where no library exists, but you don't have a time where only part of the library is available.