I think it's a harder problem on Linux -- when using shared objects -- for three reasons: - flat namespace, which you can sort of work around in some cases wit

I think it's a harder problem on Linux -- when using shared objects -- for three reasons: - flat namespace, which you can sort of work around in some cases with dlmopen() but... - ...glibc's subordinate libraries (pthreads) don't like being in the same process as different versions of glibc, and loading two different libcs in the same process creates problems - There isn't a strong check for ABI compatibility at startup, the best you can hope for is soname being set and symbol versioning Symbol versioning (especially auto-versioning) with proper sonames and ABI stability help a lot, but there is still the problem that everything needs to use the same glibc within the same process. There's also static linking, but it has its own problems, and at that point you're just doing shared linking (plus some optimizations) and copying all your dependent libraries that all still had to be compiled with the same system library, hopefully in a way that integrates with the whole system (but probably not). I took a different approach with AppFS [0] than traditional package managers: - no install step for packages - since there's no install step, you can have as many concurrent versions available as you want However, the hard problems remain. A concrete example is my library CACKey [1], which is a PKCS#11 module. PKCS#11 dictates shared objects (so no getting around it with static linking) and that the library should be thread-safe, so to deal with threading it was written to use pthreads primitives (mutexes). However, if you try to load pthreads in a process with a different version of glibc, pthreads aborts. I tried to fix this with dlmopen() [2], but this refuses to load a different version of glibc (IIRC). So, your best bet is a package manager that compiled everything in the system with the system libraries. [0] https://AppFS.net/ https://AppFS.net/ [1] https://CACKey.rkeene.org/ https://CACKey.rkeene.org/ [2] https://cackey.rkeene.org/fossil/file?name=build/libcackey_wrap.c.in&ci=2d57dd9864e513ac1cee6d64a5f969b1d224c00b https://cackey.rkeene.org/fossil/file?name=build/libcackey_w...