You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don’t want dynamic libraries. Linux and Windows isn’t really any different there aside from Windows has more in the way of novice friendly tools to create redistributables.
It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first).
To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).
For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible.
I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system.
All it takes is one dynamic dependency to break (libstdc++ is not stable for example).
> For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible.
It’s actually not as dramatic as that and you can still ship libc as a dependency of your project like I described if you really had to. It’s vaguely equivalent in that regard to a Docker container or chroot except you’re not sandboxing the applications running directory.
This is something I’ve personally done many times on both Linux and a some UNIXes too (because I’ve had a binary but for various different reasons didn’t have access to the source or build tools).
I’ve even run Linux ELFs on FreeBSD using a series of hacks, one of them being the above.
Back before Docker and treating servers like cattle were a thing, us sysadmins would often have some highly creative solutions running on our pet servers.
> I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example).
There are a couple of commonly used flags but usually reading through the Makefile or configure.sh would give the game away. It has been a while since my build pipelines required me to build the world from source but I don’t recall running into any issues I couldn’t resolve back when I did need to commonly compile stuff from source.
the gcc C++ ABI hasn't changed since v5 (or has changed in backwards-compatible ways). There was a small (but important) change between 4 and 5. Earlier versions did have much mor churn, but it's simply not true to say "every minor version of gcc" at this point.
Or statically compile if you don’t want dynamic libraries.
Indeed. I do not understand why dynamic linking is still routinely used as part of so many software deployments. A lot of the arguments for using it that once made sense are now obsolete; some have been for a very long time. It's not that it's never useful, but it seems to be used almost by default in a lot of situations, even when a simple, static link would result in software that is both more efficient and more reliable.
It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first).
To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).