1

Is it possible to make object code (*.o) on newer gcc , and then link them (along with standard libraries like libc) on another machine. If the machines are identical it should likely work, but I am interested in a case where the 2 versions are different. This assumes that the basic architecture of machines (but not necessarily all things) like while both system are linux, they are of different flavors or different kernel versions (no mixing mac,linux and windows). As is well known standard repos of various linux distros have different standard libraries

A very simple example of mine worked, but I want to know if this possible in general, and what are the usual pitfalls?

It related to Dev production libc/libstdc++ mismatch [link libc.so.6/libstdc++.so.6 with older version] but felt this was specific enough to warrant a separate question

Community
  • 1
  • 1
ssj3892414
  • 25
  • 5

1 Answers1

1

The only guarantee you have is ABI forwards compatibility. This means that old compiled binaries should still run against newer versions of the standard libraries (both glib and libstdc++ do their best to make this work).

What you propose is combining the building blocks of those binaries built against different libraries and with different compilers. This can fail miserably for a multitude of reasons:

  • an inlined function that assumes a certain bibary layout of its arguments gets passed a newer version of the same type.
  • a function modifies some internal library global state (thread local storage, errno, etc.) but the object files built against the new library do so differently or the global has been changed/removed.
  • compiler/library ABI is slightly different. This can be due to numerous reasons, including optimization options.

In the best case you get a linker error due to mismatching symbols, but I wouldn't count on it preventing worse.

Note that at least on Linux, static libraries are just a set of object files so all the above applies to them as well.

Don't mix and match on this level, just don't. Save yourself and everyone else the trouble!

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • Interesting info, though in my case the compilers versions are the same (but libc and libstdc++ and related versions are newer). It'd be great if you can look at my other question, and suggest some workaround. I'll most likely follow this advice, but waiting for some more time, before marking this as answer. Thanks – ssj3892414 Aug 12 '16 at 17:16
  • @ssj3892414 Due to the forward compatibility, you should always build against the oldest version of glibc/libstdc++ you want to support. Then everything should work. – rubenvb Aug 12 '16 at 18:06
  • @ssj3892414 - On rpm based distributions, you can check the highest API version that a library support by running `rpm -q --provides glibc`. Replace `glibc` with the appropriate library package. I'm pretty sure there is similar command for `apt`itude based distributions. The highest API version __common to both__ the old and new should be used. To guarantee this, always compile on the system with the lower versions. – alvits Aug 12 '16 at 21:13