1

I'm reading a book about gcc and the following paragraph puzzles me now:

Furthermore, shared libraries make it possible to update a library with- out recompiling the programs which use it (provided the interface to the library does not change).

This only refers to the programs which are not yet linked, right? I mean, in C isn't executable code completely independent from the compiler? In which case any alteration to the library, whether its interface or implementation is irrelevant to the executable code?

Natan Streppel
  • 5,759
  • 6
  • 35
  • 43
bsky
  • 19,326
  • 49
  • 155
  • 270
  • related: http://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries – Vinicius Kamakura Feb 05 '14 at 19:22
  • 2
    This is [dynamic linking](http://en.wikipedia.org/wiki/Dynamic_linker). The external symbols are resolved at 'load time'. There's an excellent technical article, with a focus on gcc and GNU/Linux [here](http://www.akkadia.org/drepper/dsohowto.pdf). – Brett Hale Feb 05 '14 at 19:23

3 Answers3

2

A shared library is not linked until the program is executed, so the library can be upgraded/changed without recompiling (nor relinking).

EG, on Linux, one might have

    /bin/myprogram

depending upon

    /usr/lib64/mylibrary.so

Replacing mylibrary.so with a different version (as long as the functions/symbols that it exports are the same/compatible) will affect myprogram the next time that myprogram is started. On Linux, this is handled by the system program /lib64/ld-linux-x864-64.so.2 or similar, which the system runs automatically when the program is started.

Contrast with a static library, which is linked at compile-time. Changes to static libraries require the application to be re-linked.

As an added benefit, if two programs share the same shared library, the memory footprint can be smaller, as the kernel can “tell” that it's the same code, and not copy it into RAM twice. With static libraries, this is not the case.

BRPocock
  • 13,638
  • 3
  • 31
  • 50
  • This answer includes the other benefit of *shared* libraries - namely, that programs can share the same library code in memory. – Brett Hale Feb 05 '14 at 19:33
  • Thank you. This made me realize I don't understand a more basic thing: Does any OS keep unlinked code? I thought that when the c applications are downloaded, in case they are open-source, gcc(or another compiler) compiles them and then links them. So code is either stored as c source code or executable(but not unlinked). – bsky Feb 05 '14 at 19:42
  • The unlinked parts are usually object files (traditionally: `.o`) or archives of object code (traditionally: `.a`) and are normally discarded after compilation. (NB. Open Source doesn't mean "compiled from source," it means "you have a legal right to read and edit the source code") – BRPocock Feb 05 '14 at 23:39
1

No, this is talking about code that is linked. If you link to a static libary, and change the library, the executable will not pick up the changes because it contains its own copy of the original version of the library.

If you link to a shared library, also known as dynamic linking, the executable does not contain a copy of the library. When the program is run, it loads the current version of the library into memory. This allows you to fix the library, and the fixes will be picked up by all users of the library without needing to be relinked.

Barmar
  • 741,623
  • 53
  • 500
  • 612
0

Libraries provide interfaces (API) to the outside world. Applications using the libraries (a .DLL for example) bind to the interface (meaning they call functions from the API). The library author is free to modify the library and redistribute a newer version as long as they don't modify the interface.

If the library authors were to modify the interface, they could potentially break all of the applications that depend on that function!

bblincoe
  • 2,393
  • 2
  • 20
  • 34