4 ms·

> libc.so.6.1 My brain hurts-- if libc.so.6.1 is a nightmare, then what is the utility of having the libc.so.6 soname numbering at all? I'll put it in a more

> libc.so.6.1 My brain hurts-- if libc.so.6.1 is a nightmare, then what is the utility of having the libc.so.6 soname numbering at all? I'll put it in a more effective wrong-thing-on-the-internet style for receiving responses: There's no point in using NixOS. Just use lib.so.versionNumber. (Sorry) :)

deleted 5y ago
[deleted]
jcranmer 5y ago
The problem with sonames for libc is that libc is too foundational of a library to really have multiple incompatible versions running around [1]. There is no way for an application to have multiple versions of libc in its memory space. When you live in a modern world where applications will pull in multiple third-party packages that all depend on core packages, those core packages better be extremely good about backwards compatibility or there is immense pain on adopting new versions (see also Python 2->3 transition). [1] Or, perhaps more accurately, an incompatible version of libc requires the creation of an entire distinct target triple. You can have multiple incompatible versions if you've got a multiarch setup of some kind (like 32-bit and 64-bit x86 code on the same system), but an application can't simultaneously use both in the same process in such systems still.
- Arnavion 5y ago
  It's partly a Linux-specific problem. Windows programs are fine with having multiple copies of MSVCRT loaded into the same process. It's often unavoidable; any process that loads plugin libraries will have its own CRT plus other CRTs pulled in by the plugins in its address space. Just open up some process in procexp and see how many msvcrt##.dll you find loaded. It means every library has to be careful about providing both malloc and free calls in their API. Eg if a library has a `Foo *create_foo(void)` it has to provide a `void delete_foo(Foo*)`, instead of expecting the user to call `free(the_foo)` because that `free` might be from the wrong CRT. With Linux libraries I often find that you have a `create_foo` but no `delete_foo`, and you're expected to just `free` it. I assume Linux libraries never took this much care historically because software was generally open-source, so everyone was getting their software from distro repos that rebuilt the world to link to a single libc.
  - yjftsjthsd-h 5y ago
    You should know that HN lets you prefix stars with a backslash to escape them, so your text ends up saying, ex. foo*bar and bar*baz rather than foobar and barbaz
    - Arnavion 5y ago
      I know. I fixed it shortly after I posted the comment.
  - jcranmer 5y ago
    glibc serves multiple purposes, and these purposes are broken up into separate libraries on Windows. One of those purposes is to act as the C standard library, which is what is provided by msvcrt.dll. But another purpose is to act as the library of system services, which is provided by kernel32.dll instead. The actual functionality that glibc broke in this specific ABI break is really the sort of functionality that is provided by kernel32.dll (i.e.., that's where the SEH functions live) on Windows. And you can't provide multiple copies of kernel32.dll on Windows, just like you can't have multiple copies of glibc.
    - Arnavion 5y ago
      setjmp, longjmp, jmp_buf are defined in the CRT, not in kernel32. Of course their implementations will eventually depend on kernel32, but that's not relevant to the callers of setjmp/longjmp.
      - jcranmer 5y ago
        If glibc were set up to have a kernel32/CRT divide like Windows does, I suspect the ABI breakage would have impacted the kernel32 side of the divide, given that the rationale was for better support of hardware stuff in s390. Of course, in Windows, setjmp/longjmp/jmp_buf being the C way of doing things, the implementations live in CRT-land, but the underlying implementation (being essentially SEH/unwind) actually lives in kernel32.
- jancsika 5y ago
  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.
rwmj 5y ago
I remember using Linux with libc.so.4 & .5 (which were not based on glibc code). libc 4 used a pre-ELF scheme called a.out, and libc 5 used ELF. When Linux distros started to adopt GNU libc 2.x, the soname was 6 (to be obviously higher than previous versions) and they promised the new ELF symbol versioning scheme which meant that the version number would never have to change again. So here we are.
- marcodiego 5y ago
  I've been using linux since late 90's and the only related thing I remember was to have to install an "old" libc to be able to run kylix. Do you have more info on this event? Seems to have completely vanished from my memory.
  - rwmj 5y ago
    I guess you may not remember the a.out to ELF transition, which was a "Big Bang" event. Before ELF, shared libraries did not use position independent code and so load addresses had to be globally coordinated (with extra space left for a library to grow in size!). That was libc.so.4 (old libc, a.out) -> libc.so.5 (old libc, ELF) and Linux 1.2. I don't recall if there were libc < 4. Google says this happened in around 1995. The libc.so.5 (old libc, ELF) to libc.so.6 (glibc 2.0) transition happened a little later in 1997.
    - marcodiego 5y ago
      I remember the a.out to elf transition because the first distro I used had Doom in its repos. When I installed it complained that a.out format wasn't supported anymore. IIRC I tried kylix in 1999. It still requiring libc5 is strange. Well... those were not best inprise/borland days indeed.
- yjftsjthsd-h 5y ago
  > I remember using Linux with libc.so.4 & .5 (which were not based on glibc code). What libc implementation was that, then? I thought glibc was the first to support Linux.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

jcranmer 5y ago

The problem with sonames for libc is that libc is too foundational of a library to really have multiple incompatible versions running around [1]. There is no way for an application to have multiple versions of libc in its memory space. When you live in a modern world where applications will pull in multiple third-party packages that all depend on core packages, those core packages better be extremely good about backwards compatibility or there is immense pain on adopting new versions (see also Python 2->3 transition). [1] Or, perhaps more accurately, an incompatible version of libc requires the creation of an entire distinct target triple. You can have multiple incompatible versions if you've got a multiarch setup of some kind (like 32-bit and 64-bit x86 code on the same system), but an application can't simultaneously use both in the same process in such systems still.

Arnavion 5y ago
It's partly a Linux-specific problem. Windows programs are fine with having multiple copies of MSVCRT loaded into the same process. It's often unavoidable; any process that loads plugin libraries will have its own CRT plus other CRTs pulled in by the plugins in its address space. Just open up some process in procexp and see how many msvcrt##.dll you find loaded. It means every library has to be careful about providing both malloc and free calls in their API. Eg if a library has a `Foo *create_foo(void)` it has to provide a `void delete_foo(Foo*)`, instead of expecting the user to call `free(the_foo)` because that `free` might be from the wrong CRT. With Linux libraries I often find that you have a `create_foo` but no `delete_foo`, and you're expected to just `free` it. I assume Linux libraries never took this much care historically because software was generally open-source, so everyone was getting their software from distro repos that rebuilt the world to link to a single libc.
- yjftsjthsd-h 5y ago
  You should know that HN lets you prefix stars with a backslash to escape them, so your text ends up saying, ex. foo*bar and bar*baz rather than foobar and barbaz
  - Arnavion 5y ago
    I know. I fixed it shortly after I posted the comment.
- jcranmer 5y ago
  glibc serves multiple purposes, and these purposes are broken up into separate libraries on Windows. One of those purposes is to act as the C standard library, which is what is provided by msvcrt.dll. But another purpose is to act as the library of system services, which is provided by kernel32.dll instead. The actual functionality that glibc broke in this specific ABI break is really the sort of functionality that is provided by kernel32.dll (i.e.., that's where the SEH functions live) on Windows. And you can't provide multiple copies of kernel32.dll on Windows, just like you can't have multiple copies of glibc.
  - Arnavion 5y ago
    setjmp, longjmp, jmp_buf are defined in the CRT, not in kernel32. Of course their implementations will eventually depend on kernel32, but that's not relevant to the callers of setjmp/longjmp.
    - jcranmer 5y ago
      If glibc were set up to have a kernel32/CRT divide like Windows does, I suspect the ABI breakage would have impacted the kernel32 side of the divide, given that the rationale was for better support of hardware stuff in s390. Of course, in Windows, setjmp/longjmp/jmp_buf being the C way of doing things, the implementations live in CRT-land, but the underlying implementation (being essentially SEH/unwind) actually lives in kernel32.
jancsika 5y ago
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.

rwmj 5y ago

I remember using Linux with libc.so.4 & .5 (which were not based on glibc code). libc 4 used a pre-ELF scheme called a.out, and libc 5 used ELF. When Linux distros started to adopt GNU libc 2.x, the soname was 6 (to be obviously higher than previous versions) and they promised the new ELF symbol versioning scheme which meant that the version number would never have to change again. So here we are.

marcodiego 5y ago
I've been using linux since late 90's and the only related thing I remember was to have to install an "old" libc to be able to run kylix. Do you have more info on this event? Seems to have completely vanished from my memory.
- rwmj 5y ago
  I guess you may not remember the a.out to ELF transition, which was a "Big Bang" event. Before ELF, shared libraries did not use position independent code and so load addresses had to be globally coordinated (with extra space left for a library to grow in size!). That was libc.so.4 (old libc, a.out) -> libc.so.5 (old libc, ELF) and Linux 1.2. I don't recall if there were libc < 4. Google says this happened in around 1995. The libc.so.5 (old libc, ELF) to libc.so.6 (glibc 2.0) transition happened a little later in 1997.
  - marcodiego 5y ago
    I remember the a.out to elf transition because the first distro I used had Doom in its repos. When I installed it complained that a.out format wasn't supported anymore. IIRC I tried kylix in 1999. It still requiring libc5 is strange. Well... those were not best inprise/borland days indeed.
yjftsjthsd-h 5y ago
> I remember using Linux with libc.so.4 & .5 (which were not based on glibc code). What libc implementation was that, then? I thought glibc was the first to support Linux.

deleted 5y ago

[deleted]