From: jgd@cix.co.uk   
      
   In article <10cjo0e$2f7tf$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)   
   wrote:   
      
   > But RHEL clones still exist. Rocky, Alma, Oracle, Amazon etc..   
   > Redhat's changes may have reduced compatibility from 100%   
   > to 99.95%, but my impression is that the industry in general   
   > consider the compatibility acceptable.   
      
   Yup, it is. If you're selling closed-source binary software, which is   
   still big business in some sectors, then if you sell for Linux, you must   
   support RHEL _and_ its work-alikes. Doing this isn't actually too hard.   
      
   You run your central build machines on real RHEL, and pay for support on   
   that. Your development and test machines run work-alikes. You make sure   
   everything you ship was built on the central build machines.   
      
   This works well. Compatibility from RHEL onto the work-alikes gets tested   
   far more than the other way around, by the work-alike producers, and the   
   ISVs who work this way. It allows your customers to standardise on a   
   work-alike and be supported.   
      
   RHEL (and work-alikes) have other advantages. They have long and   
   predictable support lives, and excellent compatibility of software built   
   on older point releases onto newer point releases (e.g., the current RHEL   
   9.6 and the 9.7 due in November). You can update your development, build   
   and test machines onto new point releases as they appear (after   
   confirmatory testing, of course!) and your build machines remain on a   
   supported version, with no need to isolate them or use weird security   
   methods. You can thus encourage your customers to update, so that they   
   stay secure.   
      
   RHEL freezes its glibc version when a new major version ships. They apply   
   bug-fix and security updates to it, of course. Glibc has strong forwards   
   compatibility commitments: every symbol is versioned, and behaviour   
   changes require new versions of affected symbols. This means that   
   anything built against a given version of glibc will run on any later   
   version (for the same architecture, pointer size, etc).   
      
   Red Hat offers optional "GCC Toolsets" for supported RHEL. These give you   
   a newer version of gcc, installed as an optional extra, with a path of   
   its own and not affecting the system compiler. This also comes with   
   static versions of libstdc++ and libgcc, the support libraries for the   
   compiler, and some scripts for Gnu ld. The effect of all this is that   
   when you build software on, say, RHEL8, which comes GCC 8.x, using GCC   
   Toolset 11, which provides GCC 11, you get binaries which will run on an   
   ordinary RHEL8 system without any special tools installed. The GCC 11   
   support library functions that aren't in GCC 8's support libraries get   
   statically linked into your binaries.   
      
   The effect of that is that you can build C and C++ code on an RHEL system   
   with a GCC Toolset, and as far as the languages are concerned, your code   
   will run correctly on any Linux with equal or later glibc and gcc to the   
   RHEL you used.   
      
   That sounds terrifying, but it works. It probably stays working because   
   Red Hat, who are significant contributors to both glibc and gcc, make   
   sure that it stays working.   
      
   That means that will a single x86-64 build on RHEL 8.10, I can support   
   all the RHEL work-alikes. SLES, Ubuntu, and Debian. I also know it's   
   extremely likely to work on any Linux with glibc 2.28 (the version RHEL8   
   uses) or later and GCC 8 (ditto) or later. This is great from my point of   
   view. Doing extra builds would be more expensive, and testing them   
   thoroughly would be much more expensive.   
      
   I don't know if Red Hat set out to produce the best Linux for building   
   closed-source binary software on, but they achieved it.   
      
   John   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)