Are Linux programs as portable as Windows programs? [closed]

Question

Maybe this is a dumm question, but it's one of these one learns from people talking here and there, and I'd be happy if a pro described the situation correctly.

Talking about standard desktop computers, I see that Windows programs are as portable as it can get. I could compile any 32-bit software with static library linking, and then put that software on a flash-drive, and it'll work on any computer in the world that's 32-bit or 64-bit. I have programs that are over 10 years old, and they still work without a single problem.

Now I program linux too, but I don't have that picture in mind when doing linux programs. I always have the picture that it should be compiled in every system where the program has to be used. A colleague told me one that it's wrong to run the same software on two computers blindly among two linux computers. But... I do that on Windows with my static executables. Can I do that in linux two?

So to summarize my question: What are the limitations to creating portable software on linux, as people do on Windows? Of course, assuming that the target computer has no libraries at all other than glibc of some arbitrary version. All libraries should be static in the model I have in my mind.

Answer 1

In the Linux world, binary compatibility is not considered to be as important as source compatibility, since the majority of the ecosystem around Linux is open source. Even when binary compatibility breaks, you can still run old programs after compiling them again. In the Windows ecosystem, this is not possible: most software is closed-source, so an user would depend on the software vendor to update the software for a new OS version. Since this basically never happens, Windows places a lot of emphasis on maintaining binary-level backcompat, to the point that 20 year old binaries can often still run.

Linux has a specification called the Linux Standard Base (LSB) that tries to provide a stable Application Programming Interface (API) for source compatibility and a more limited Application Binary Interface (ABI) for binary compatibility. It is based on POSIX and the Single Unix Specification. However, most Linux distros don't completely implement the LSB. The Red Hat-related group of distros seem to follow it more closely than the Debian- and Ubuntu-related distros.

So unfortunately, the Linux ecosystem does not feature hard guarantees regarding binary compatibility between different distributions or between different versions. In practice though, there's a reasonable amount of compatibility going on. In particular, individual distributions might provide stronger compatibility guarantees. And binaries compiled on one installation of a specific distro version can be used on any installation of that version, provided they have the same architecture – most package managers on Linux use packages with such precompiled binaries. But note that these packages are generally compiled on reference installations with tightly controlled dependencies.

In some cases, the boundaries of architecture, executable format, and OS ABI can be crossed. E.g. the WINE interface layer has an implementation of Windows' “Portable Executable” format, and reimplements significant parts of the Windows ABI, leading to limited Windows→Linux binary compatibility. Architecture boundaries can only be crossed by using emulators (e.g. you can't use software compiled for SPARC on an AMD64 system, even when using the same OS version).

The compatibility for x86 binaries on AMD64 architectures is a special case. The AMD64 instruction set was specifically engineered to be backwards-compatible to x64 (which is why it's so successful). Operating systems still need to provide special kernel-level support for running x86 binaries (which feature 32-bit pointers) on an AMD64 system (which is 64-bit), but all serious operating systems do provide that support.

Answer 2

I assume that your question is about application portability between Linux versions.

There are different kinds of API/ABI incomplitability between Linux verions. Most common ones with can affect static executables are:

1. libc versions. (e.g your app depends on glibc-specific functionality but host has a very old version or has another C library(newlib, bionic, etc))

2. Architecture. (e.g system has no 32bit libc, on ARM you care about stuff like soft/hard float, app might use SSE2/AVX2 but kernel has no idea how to keep registers after context switch )

3. System Calls/Hardware support. This is usually stuff like new kernel APIs (inotify/old dnotify). Old kernels also had no idea about IPv6, USB3.0. Some old kernel APIs might get removed in future.

Some extremely unlikely possibilities:

1. Executable format. (e.g your app is ELF but system knows only a.out)
2. Resource limits. (e.g 32bit kernel without PAE can't mmap your 40GB file)

And this is only the basics. I don't even wan't to start about problems with using Xorg or anything close to OpenGL.