3 ms·

In keeping with my confidently-wrong-on-the-internet theme: Nobody is trying to run multiple incompatible versions of glibc in a single application. The point

In keeping with my confidently-wrong-on-the-internet theme: Nobody is trying to run multiple incompatible versions of glibc in a single application. The point is to run multiple different versions of the same application on a single OS, where each version uses a different version of glibc. NixOS is wildly over-engineered for this purpose. Just use lib.so.versionNumber, full stop. And, scene. :)

assbuttbuttass 5y ago
If some library e.g. libpng depends on a particular version of glibc, and your application depends on libpng and glibc, you better hope they want the same version
- jancsika 5y ago
  I'm still not getting it. Doesn't libpng use the soname.someVersion, too?
  - assbuttbuttass 5y ago
    Well suppose to libpng depends on glibc version 6.0, but when you try to link your app it will find the latest glibc 6.1. Only one of these versions is going to get loaded at runtime. The compiler's not going to check compatibility between all the different libraries.
    - jancsika 5y ago
      If the highest number always gets chosen then what's the point of libname.so.versionNumber in the first place?
      - rlpb 5y ago
        The point is for runtime. At build time generally the latest available version is used (via a symlink) and then that version gets locked in to the resulting binary.
jcelerier 5y ago
> Nobody is trying to run multiple incompatible versions of glibc in a single application on windows multiple incompatible versions of the C runtime in the same application are mostly fine as far as I know and fairly useful, one can load a DLL built in 2003 in a program built in 2022.
- jancsika 5y ago
  What's the use case, loading plugins?
  - jcelerier 5y ago
    yes, it's pretty common in audio and I guess in other creative fields.
    - jancsika 5y ago
      It's funny you mention audio. For example, going back to the early 2000s I can't think of a single case of a user reporting such a need on the Pure Data mailing list. And there are a few thousand plugins for it. I guess Csound would be the grandaddy to check. But I have a feeling this would essentially be limited to running old proprietary plugins for which no source is available?
      - detaro 5y ago
        With all respect for it, Pure Data (nor csound) is not exactly representative of audio software with plugins overall.
        jancsika 5y ago
        The only case I can think of that's not represented would be plug-in binaries for which there is no source available.
      - jcelerier 5y ago
        > But I have a feeling this would essentially be limited to running old proprietary plugins for which no source is available? Yes, I have some songs from circa 2007-2009 which depend on windows 32-bit versions of freeware plug-ins whose developers have been MIA for 15 years now. Well, now I know better and try to only use software that I can recompile or write for my music (including pd :-)). But then I also spent 10 years not making much music because of that. I also work with artists who keep old 10.6 Macs around in case they'd have to perform one of their past songs.

assbuttbuttass 5y ago

If some library e.g. libpng depends on a particular version of glibc, and your application depends on libpng and glibc, you better hope they want the same version

jancsika 5y ago
I'm still not getting it. Doesn't libpng use the soname.someVersion, too?
- assbuttbuttass 5y ago
  Well suppose to libpng depends on glibc version 6.0, but when you try to link your app it will find the latest glibc 6.1. Only one of these versions is going to get loaded at runtime. The compiler's not going to check compatibility between all the different libraries.
  - jancsika 5y ago
    If the highest number always gets chosen then what's the point of libname.so.versionNumber in the first place?
    - rlpb 5y ago
      The point is for runtime. At build time generally the latest available version is used (via a symlink) and then that version gets locked in to the resulting binary.

jcelerier 5y ago

> Nobody is trying to run multiple incompatible versions of glibc in a single application on windows multiple incompatible versions of the C runtime in the same application are mostly fine as far as I know and fairly useful, one can load a DLL built in 2003 in a program built in 2022.

jancsika 5y ago
What's the use case, loading plugins?
- jcelerier 5y ago
  yes, it's pretty common in audio and I guess in other creative fields.
  - jancsika 5y ago
    It's funny you mention audio. For example, going back to the early 2000s I can't think of a single case of a user reporting such a need on the Pure Data mailing list. And there are a few thousand plugins for it. I guess Csound would be the grandaddy to check. But I have a feeling this would essentially be limited to running old proprietary plugins for which no source is available?
    - detaro 5y ago
      With all respect for it, Pure Data (nor csound) is not exactly representative of audio software with plugins overall.
      - jancsika 5y ago
        The only case I can think of that's not represented would be plug-in binaries for which there is no source available.
    - jcelerier 5y ago
      > But I have a feeling this would essentially be limited to running old proprietary plugins for which no source is available? Yes, I have some songs from circa 2007-2009 which depend on windows 32-bit versions of freeware plug-ins whose developers have been MIA for 15 years now. Well, now I know better and try to only use software that I can recompile or write for my music (including pd :-)). But then I also spent 10 years not making much music because of that. I also work with artists who keep old 10.6 Macs around in case they'd have to perform one of their past songs.