5

I want to make a quick fix to one of the project's .so libraries. Is it safe to just recompile the .so and replace the original? Or I have to rebuild and reinstall the whole project? Or it depends?

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
facha
  • 11,862
  • 14
  • 59
  • 82
  • Isn't it up to the Makefile to decide, what components need rebuilding? So you should see what files you must replaced. – ott-- Sep 15 '11 at 11:24
  • @ott: make isn't going to know or care about runtime .so deps unless you tell it. It definitely isn't practical to give make what it needs to make a decision about ABI. – Matt Joiner Sep 16 '11 at 09:38

5 Answers5

4

It depends. Shared library needs to be binary-compatible with your executable.

For example,

  1. if you changed the behaviour of one of library's internal functions, you probably don't need to recompile.
  2. If you changed the size of a struct (e.g. by adding a member) that's known by the application, you will need to recompile, otherwise the library and the application will think the struct is smaller than it is, and will crash when the library tries to read an extra uninitialized member that the application didn't write to.
  3. If you change the type or the position of arguments of any functions visible from the applications, you do need to recompile, because the library will try to read more arguments off the stack than the application has put on it (this is the case with C, in C++ argument types are the part of function signature, so the app will refuse run, rather than crashing).

The rule of thumb (for production releases) is that, if you are not consciously aware that you are maintaining binary compatibility, or not sure what binary compatibility is, you should recompile.

Alex B
  • 82,554
  • 44
  • 203
  • 280
  • With regards to 3: Changes to default parameters has zero effect on ABI. For cdecl calls (the default in C, and for thiscall in GCC), the caller actually cleans the stack. It's also okay to pass more parameters than expected, but not less for right-to-left calling conventions. – Matt Joiner Sep 16 '11 at 09:51
  • @Matt, I didn't mention *default* arguments, just arguments. :) Also, it's more common to end up with more arguments on the library side, rather than fewer, so the library will try to access garbage values. – Alex B Sep 16 '11 at 12:48
1

That's certainly the intent of using dynamic libraries: if something in the library needs updating, then you just update the library, and programs that use it don't need to be changed. If the signature of the function you're changing doesn't change, and it accomplishes the same thing, then this will in general be fine.

There are of course always edge cases where a program depends on some undocumented side-effect of a function, and then changing that function's implementation might change the side-effect and break the program; but c'est la vie.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
1

If you have not changed the ABI of the shared library, you can just rebuild and replace the library.

nos
  • 223,662
  • 58
  • 417
  • 506
1

If you don't change your library binary interface, it's ok to recompile and redeploy only the shared library.

Good references:

Gregory Pakosz
  • 69,011
  • 20
  • 139
  • 164
1

It depends yes.

However, I assume you have the exact same source and compiler that built the other stuff and now if you only change in a .cpp file something, it is fine.

Other things e.g. changing an interface (between the shared lib and the rest of the system) in a header file is not fine.

murrekatt
  • 5,961
  • 5
  • 39
  • 63