2

I am new to Linux programming and I wonder, is there a way to run (not recompile) my C++ executable on an older version of Linux of the same distribution?

Example: Say I compiled my code on RHEL 6 and want to run my executable on RHEL 4 or 5.

In Windows when we do this we just install the C++ runtime of the compiler version of C++.

Example: If I use VS2012 to build a C++ project using C++11, I just need to install the C++ runtime of C++11 on the client machine to run my application no matter what version of Windows I am using (of course starting from Windows XP)

LSerni
  • 55,617
  • 10
  • 65
  • 107
Ahmed Alaa
  • 465
  • 1
  • 4
  • 7
  • 1
    This might help: http://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version – Vlad Nov 20 '13 at 09:56

2 Answers2

1

The by far easiest way is to make use of the strong future compatibility of glibc and the GCC runtime libraries: compile your executable on the oldest OS you want it to run on, and it should work on anything later without recompiling (that is, some symlinks may be needed to satisfy the dependencies the executable loader is expecting).

In general it is best to compile it for each distribution you want to support, so no unexpected conflicts appear.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
0

Actually, yes - Find your apps deps (using e.g: ldd) and copy them (e.g: libstdc++.so.6) from your build system to somewhere on your target system (e.g: /mylibs). Point your app here (e.g: using patchelf's --rpath and --interpreter). Your app should run (test it!). If not, it's likely that your glibc is incompatible with the older kernel. You can solve this by recompiling the required version of glibc to support the older kernel - using the --enable-kernel=<version> ./configure switch. If your required version of glibc doesn't support that kernel version then you can supply the missing functions in .so's and load them with LD_PRELOAD.

Tunaki
  • 132,869
  • 46
  • 340
  • 423
user1976
  • 353
  • 4
  • 15
  • The only possible problems here are that 1) in time your distributed app o's actually coupled to older libraries, and 2) the district might have patched the system libraries for whatever reason which might make yours incompatible with the rest of the system. But yes, this is an option. Note e.g. Matlab delivers outdated libstdc++ which results in failing graphics drivers (mesa uses llvm which uses c++...). It may work today, but tomorrow you're screwed anyway. Linking against older libraries is then the more compatible solution. – rubenvb Jan 26 '17 at 22:08
  • The question explicitly asks to "run (not recompile)" - linking against older libraries does not answer the question! You can reduce dependencies e.g: by statically linking libstdc++. "It may work today, but tomorrow you're screwed anyway" - can you elaborate on this? I don't think that a distro is going to release an update that will break kernel api compatibility? – user1976 Jan 27 '17 at 13:11
  • Your application uses a fixed version of e.g. libstdc++. Tomorrow, the distro moves to a newer version and links the graphics driver to the new version. Your app stubbornly loads the older bundled version and everything fails. – rubenvb Jan 27 '17 at 13:13
  • The thing is that the kernel isn't the only part involved. – rubenvb Jan 27 '17 at 13:34
  • Thanks for clarifying :). First: He may not have any difficult dependencies to manage. Second: He might be ok to only support a specific version of a distro. Third: He may have statically linked libc++. Forth: In the worst case he is going to have to bundle even more things. In the case of your example he might have to bundle mesa and llvm etc.. or supply a custom loader to overcome incompatibilities. – user1976 Jan 30 '17 at 18:40
  • And that's exactly why I strongly recommend against your suggested course of action. – rubenvb Jan 30 '17 at 18:48
  • I think your recommendation is valuable *but* it is not an answer to the question. – user1976 Jan 31 '17 at 10:47