0

Does linking libgcc statically improve backwards compatibility of binaries on Linux?

Are there Linux distros that doesn't ship it by default? Or maybe older Linuxes have one with an older, incompatible ABI?

  • What are you trying to accomplish? No, static linking doesn't help backwards compatibility of newly built executables. Unless **you have a collection of static libraries** that you need to link to, there isn't much reason. – David C. Rankin Mar 26 '15 at 23:12
  • So the answer is "no" to the other questions too? –  Mar 27 '15 at 14:46
  • I understand that static linking _on a new machine_ doesn't improve backwards compatibility because of the linker's braindead limitation to always choose the latest symbol versions it finds in glibc when linking. I am particularly interested here in the _availability_ and _binary compatibility_ of libgcc in general. To put it another way, why is there an option to link libgcc statically separatedly from -static to begin with? –  Mar 27 '15 at 14:51
  • 1
    I have fought this battle before on different fronts building and cross-compiling assembly code across different architectures. You have 2 primary sets of standard libs that can either be dynamic or static. First being the standard architecture libraries that provide/enable basic I/O functionality (e.g. ld-linux.so.2, and its static friends) and second gcc standard libs (e.g. libgcc, etc..) that control the functionality of the final ELF executable behavior. Gnu can do a much better job than I. [Link Options](https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html) helped with details. – David C. Rankin Mar 27 '15 at 16:49

0 Answers0