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)
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.
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.
Related
I am building an application using Qt C++ and I want it to run on windows computers without having to install VC Redistributables. Apparently when user tries to run the application an error pops that says that VCRUNTIME140.dll is missing.
Build both Qt and your application using compiler option /MT?
https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170
I recommend using GCC (i.e. MinGW) as the compiler. If you do that, your app will generall depend on the msvcrt.dll that comes with Windows and doesn't need to be installed specially (but it depends on exactly how the GCC compiler is configured). It will also possibly depend on some GCC runtime library DLLs that you can just put in the same directory as your EXE.
MSYS2 is a good development environment for using MinGW on Windows: https://msys2.org
I also made a useful set of tools that is capable of cross-compiling statically-linked MinGW/Qt applications from Linux: https://github.com/DavidEGrayson/nixcrpkgs
The Qt applications I build with nixcrpkgs come out as single, standalone EXEs that do not need to be shipped with any DLLs.
I have build servers that run Ubuntu 18.04 (in a Docker container), but I need to build binaries (various static and shared libraries and executables) for older versions of Ubuntu (e.g. 16.04), without having to install an older version of the OS.
Currently we use sysroot toolchains (that include compiler and libraries etc) and CMake toolchain files for building for other targets (e.g. ARM Poky/Yocto), and it would be ideal if we could use the same approach for building for older (or potentially newer) versions of Ubuntu.
Is it possible?
Anything is possible, but the easiest thing you can do is create a new Docker image (or some other type of machine) with an older OS on it. Then everything will "just work."
If you really don't want to do that, you need to identify all the dependencies, starting with libc, which have symbols missing on the older platform, then figure out how to avoid using those symbols. This will probably waste a ton of time, especially considering you already have one build container (making a second one shouldn't be hard).
I use install Arch Linux with duel booted Linux Mint 18.1 .In my college we have lubuntu 16.04 and Ubuntu 14.04 installed. I have also enabled testing repos in arch Linux so I get newer packages, thus due to this when I compile any C++ program on Arch it won't run on Linux Mint due to version of shared libraries don't match in mint.
like libMango.so.64 is in arch and libMango.so.60 is on mint. How can I overcome with this ?
so I am asking for how can I compile any C/C++ with newer compiler and shared libraries to to run fine with old shared libraries ? Just like I compile 32 bit programs on 64 bit machine with -m32 flag , is there flag for old shared libraries too ?
I am using gcc 8.1.
how can I compile any C/C++ with newer compiler and shared libraries to to run fine with old shared libraries ?
You cannot do that reliably if the API (or even the ABI, including size and alignment of internal structures, offsets of fields, vtables organization) of those libraries have changed incompatibly.
In general, you'll better recompile your source code on the other computer (and your college might forbid that, if that source is unrelated to your education). BTW, if your source code sits in some git repository (e.g. github if it is open source) transferring on multiple computers is very easy.
Some very few libraries make genuine (and documented) efforts on being compatible with other versions of them in binary form (e.g. at the ABI level), but this is not usual. The Unix and free software tradition is to care about source level compatibility. And the POSIX standard cares only about source compatibility.
You might consider using some chroot-ed environment (see chroot(2) and path_resolution(7) & credentials(7)) to have the essential parts of your older distribution on your newer one. Details are distribution specific (on Debian & Ubuntu, see also schroot and debootstrap). You could also consider running a full distribution in some VM, or using containers à la Docker.
And you might try to link (locally) your executable statically, so compile and link with g++ -static
Generated an executable on Linux 32-bit Ubuntu 11 and tested it on a 32-bit Ubuntu 10 and it failed with a "GLIBC_2.15" not found.
Cyrhon FAQ section says:
Under Linux, I get runtime dynamic linker errors, related to libc. What should I do? The executable that PyInstaller builds is not
fully static, in that it still depends on the system libc. Under
Linux, the ABI of GLIBC is backward compatible, but not forward
compatible. So if you link against a newer GLIBC, you can't run the
resulting executable on an older system. The supplied binary
bootloader should work with older GLIBC. However, the libpython.so and
other dynamic libraries still depends on the newer GLIBC. The solution
is to compile the Python interpreter with its modules (and also
probably bootloader) on the oldest system you have around, so that it
gets linked with the oldest version of GLIBC.
and
How to get recent Python environment working on old Linux distribution? The issue is that Python and its modules has to be
compiled against older GLIBC. Another issue is that you probably want
to use latest Python features and on old Linux distributions there is
only available really old Python version (e.g. on Centos 5 is
available Python 2.4).
I'm building a large C++ project using cmake on ubuntu 12.04 and then taking the resulting binary package and trying to run it on ubuntu 11.04. However the program fails saying it needs glibc version 2.14 but can only find up to version 2.13.
How can I find out exactly why glibc=>2.14 is required?
Unlike most libraries, glibc versions its symbols. Every symbol is tagged with a value (e.g. "GLIBC_2.3.4") representing the version of the library where it's interface was last changed. This allows the library to contain more than one version of a given symbol and support binaries compiled against older versions while preserving the ability to evolve. You can see this detail with objdump -T /lib/libc.so.6.
Basically, something in your app was linked against a symbol that was changed since 11.04. Try objdump -T on your binary and see what tags it's looking for.
But broadly, backwards compatibility doesn't work like that in Linux. If you want something to run on older software, you should build it on older software. It's possible to set up a backwards-compatible toolchain on more recent distros, but it's not the default.
When you build your C++ project, it will link to the version of the glibc library on your 12.04 installation. What are the linker options in your build command?
Without knowing exactly what you are building, I'd say you might be better off building on 11.04 and then running on 12.04.