3 ms·

> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages

> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers. But this isn’t true. Many distros package major versions of GCC/LLVM as separate packages, so you install and use more than one version in parallel, no Docker/etc required It can indeed be true for some things-such as the C library-but often not for the compilers

torginus 8mo ago
The closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.
- skissane 8mo ago
  To give a concrete example of what I was talking about, RHEL has “gcc-toolset” for installing multiple GCC versions in parallel: https://developers.redhat.com/articles/2025/04/16/gcc-and-gcc-toolset-versions-rhel-explainer https://developers.redhat.com/articles/2025/04/16/gcc-and-gc...
  - torginus 8mo ago
    this seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/ and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.
    - skissane 8mo ago
      In RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9. In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions) e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux. Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)
pjmlp 8mo ago
Until the day there is that symlink, or environment variable with the incorrect value.

torginus 8mo ago

The closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.

skissane 8mo ago
To give a concrete example of what I was talking about, RHEL has “gcc-toolset” for installing multiple GCC versions in parallel: https://developers.redhat.com/articles/2025/04/16/gcc-and-gcc-toolset-versions-rhel-explainer https://developers.redhat.com/articles/2025/04/16/gcc-and-gc...
- torginus 8mo ago
  this seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/ and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.
  - skissane 8mo ago
    In RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9. In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions) e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux. Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)

pjmlp 8mo ago

Until the day there is that symlink, or environment variable with the incorrect value.