10

With respect to the following link: http://www.archlinux.org/news/libpnglibtiff-rebuilds-move-from-testing/

Could someone explain to me why a program should be rebuilt after one of its libraries has been updated?

How does that make any sense since the "main" file is not changed at all?

Adam Liss
  • 47,594
  • 12
  • 108
  • 150
stratis
  • 7,750
  • 13
  • 53
  • 94

3 Answers3

19

If the signatures of the functions involved haven't changed, then "rebuilding" the program means that the object files must be linked again. You shouldn't need to compile them again.

An API is contract that describes the interface to the public functions in a library. When the compiler generates code, it needs to know what type of variables to pass to each function, and in what order. It also needs to know the return type, so it knows the size and format of the data that will be returned from the function. When your code is compiled, the address of a library function may be represented as "start of the library, plus 140 bytes." The compiler doesn't know the absolute address, so it simply specifies an offset from the beginning of the library.

But within the library, the contents (that is, the implementations) of the functions may change. When that happens, the length of the code may change, so the addresses of the functions may shift. It's the job of the linker to understand where the entry points of each function reside, and to fill those addresses into the object code to create the executable.

On the other hand, if the data structures in the library have changed and the library requires the callers to manage memory (a bad practice, but unfortunately common), then you will need to recompile the code so it can account for the changes. For example, if your code uses malloc(sizeof(dataStructure)) to allocate memory for a library data structure that's doubled in size, you need to recompile your code because sizeof(dataStructure) will have a larger value.

Adam Liss
  • 47,594
  • 12
  • 108
  • 150
  • In other words you are saying that re-linking is essential only when the functions of a library are updated. However, in practise we don't rebuild that often despite the constant library updates. How is that so? – stratis Apr 22 '12 at 18:51
  • 1
    Is the library linked statically or dynamically? Dynamic libraries are loaded at runtime, while static libraries are linked into the executable as it's built. – Adam Liss Apr 22 '12 at 19:39
  • I deleted my previous comment and I am re-writing my question: With respect to what you say in the 3rd paragraph about the function addresses: Let's assume we have a library with 2 functions; and . Now all is compiled and running fine. According to your suggestion if I put a simple print statement inside the first method then do I have to 're-link' my program to the library because of the new code length? If not, then please explain in which case rebuilding would be appropriate. – stratis Apr 23 '12 at 13:44
  • 2
    If the library is linked statically, yes. Otherwise, how would the executable know about the changes? If the library is linked dynamically, it has its own index and "glue code" that keeps track of its functions' entry points. – Adam Liss Apr 23 '12 at 21:29
  • 1
    Fair enough. But then why libpng and libtiff in my original post (which are linked dynamically) require 're-linking'? What happened to their "glue code"? P.S. I am talking in general and not looking at the specific libraries... – stratis Apr 23 '12 at 21:50
  • The error in your original link complains that `libpng14.so.14` is missing and suggests reinstalling `librsvg`. It sounds like (an old version of?) `librsvg` depends on that particular version of `libpng`, so the link fails after it's replaced. Perhaps someone more familiar with those libraries can confirm. – Adam Liss Apr 23 '12 at 23:09
  • Great. One last question then(promise); Under which circumstances can such a link fail? – stratis Apr 25 '12 at 10:24
  • 1
    The most common reason (and the one shown on the page you linked) is that the library file is missing, but there could be many other reasons. For example, a particular function may not be present in the library, or the linker may be looking in the wrong place for the library, or the library file could be corrupted. – Adam Liss Apr 25 '12 at 22:52
7

There are two kinds of compatibility: API and ABI.

API compatibility is about functions and data structures which other programs may rely on. For instance if version 0.1 of libfoo defines an API function called "hello_world()", and version 0.2 removes it, any programs relying on "hello_world()" need updating to work with the new version of libfoo.

ABI compatibility is about the assumptions of how functions and, in particular, data structures are represented in the binaries. If for example libfoo 0.1 also defined a data structure recipe with two fields: "instructions" and "ingredients" and libfoo 0.2 introduces "measurements" before the "ingredients" field then programs based on libfoo 0.1 recipes must be recompiled because the "instructions" and "ingredients" fields will likely be at different positions in the 0.2 version of the libfoo.so binary.

user268396
  • 11,576
  • 2
  • 31
  • 26
  • Could you provide an example where after an update I wouldn't need to rebuild 'my program'? – stratis Apr 22 '12 at 18:52
  • Say you had code computing a value from the fibonacci sequence through a function `int fib(int index)` . Suppose in libfoo 0.1 the function solves this problem recursively (i.e: `fib(n) = fib(n-1)+fib(n-2)`) and in libfoo 0.2 the authors realised there's a closed form solution and applied it for a major speed boost and memory usage reduction. The behaviour of the function is "functionally" identical. The signature and location of the function remain the same. So there's no need for recompilation. – user268396 Apr 22 '12 at 20:47
  • I'm confused here... @Adam Liss implies otherwise! Please read my comment under his post. – stratis Apr 23 '12 at 13:43
2

What is a "library"?

If a "library" is only a binary (e.g. a dynamically linked library aka ".dll", ".dylib" or ".so"; or a statically linked library aka ".lib" or ".a") then there is no need to recompile, re-linking should be enough (and even that can be avoided in some special cases)

On the other hand, libraries often consist of more than just the binary object - e.g. the header-files might include some in-line (or macro) logic. if so, re-linking is not enough, and you might to have to re-compile in order to make use of the newest version of the lib.

umläute
  • 28,885
  • 9
  • 68
  • 122
  • What about statically linked libraries? – Adam Liss Apr 22 '12 at 14:56
  • @adam-liss: well, with statically linked libraries, your binary is self-contained (with respect to the library), so if you don't care for bugfixes/... in the new version of the library you don't have to recompile/relink at all. if you want any new features/fixes from the library to have an effect in your application, the same principle applies: if what is seen in the header-files changes (the public API + some macro/inline glue), you must recompile; if only the implementation of the library changes, it is enough to re-link – umläute Apr 23 '12 at 11:30