4 ms·

I agree. I recall a talk from Linux Torvalds on how bad the glibc folks break things and why he won't ship a binary version of his scuba tool. If the binary bre

I agree. I recall a talk from Linux Torvalds on how bad the glibc folks break things and why he won't ship a binary version of his scuba tool. If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel.

sylware 3y ago
This has the case for 10 years with games on steam. The worst being libstdc++ ABI issues still around because many devs forget to statically link their c++ libs with -static-libstdc++. Because in windows, ABI stability is really good and then devs are used to that.
- zer0zzz 3y ago
  As far as I understand, Windows solves this libc++ versioning issue using the side by side cache. I guess this is a little bit like flatpack.
  - sylware 3y ago
    I think there are very few c++ ABI versions on windows and it is easy to select the one you want until it is installed, they can be there side by side.
  - p_l 3y ago
    Windows solves this issue by not making language runtime part of the OS libraries in a way that pollutes other libraries. That means that you can have your application linked with library A version X, and load another library that is linked with library A version Y, and so long as certain practices are followed, everything works because you're not getting cross-contamination of symbols. Meanwhile on Linux the defaults are quite different, and I can't load OpenGL ICD driver that depends on GLIBC_2.38 symbol on application that was loaded with glibc-2.37. Moreso, a lot of APIs will use malloc() and free() instead of language-independent allocator, unless the allocation comes from kernel. And no, you can't mix and match those.
    - zlg_codes 3y ago
      What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use instead of malloc and free?
      - SubjectToChange 3y ago
        I suppose they meant a "libc independent" allocator, e.g. jemalloc/tcmalloc/mimalloc/etc. Although, using such allocators comes with complications of their own: https://lwn.net/Articles/761502/ https://lwn.net/Articles/761502/
      - p_l 3y ago
        The OS provided memory allocators - HeapAlloc, its wrappers GlobalAlloc and LocalAlloc (remainders of 16bit era), VirtualAlloc (page granularity, can be compared to MAP_ANONYMOUS with mmap(), and CoTaskMemAlloc which can be shared across COM processes + their respective "free" functions. malloc() is explicitly called out in documentation as "runtime dependant". Similarly other OSes used to have memory allocation services that weren't linked in any way to a language runtime - VMS has several calls, all language independent, ranging from low-level equivalents of mmap() to malloc-alternative. And yes, a big chunk of Windows portability is that various APIs use those language-independent calls internally, and so can developer in order to avoid creating issues - and documentation promotes those language independent methods. At no point you get into situation with Windows API that you call free() on memory allocated by malloc() from a different libc. In comparison, the available language-independent APIs without using any special libraries on Linux, are to directly call mmap() and sbrk() through inline assembly (beware the glibc wrappers!).
        account42 3y ago
        malloc in (g)libc isn't any more language dependent than HeapAlloc or VirtualAlloc. Both have a stable ABI that can be used by any language.
        3y ago
  - okanat 3y ago
    Windows standard C and C++ ABI is stable since 2017. So the last 3 releases of the Visual C Compiler and C runtime hasn't changed the ABI. However Windows also has a lower level system API / ABI i.e. Win32 that's always stable all the way to Win 95. WinSXS sometimes helps for certain legacy apps too. This allows apps using different C libraries to work together. Win32 contains everything about the OS interface. Creating windows, drawing things, basic text, allocating pages from the OS, querying users, getting info about files is all stable. Win32 is the lower level of the C library. There is also a better separation of the functions in different DLLs. Win32 has multiple DLLs that has different jobs and they are mostly orthogonal. Kernel32 contains core almost system call stuff. Shell32 contains interactions with the OS shell i.e. creating windows, message boxes, triggering different UIs. The surrounding libraries like DirectX / DirectPlay / DirectWrite that are also used by the games are also part of the system libs starting from 7. They are also stable. On Linux world there is no separation of the system level libraries and normal user libraries. Glibc is just another library that one depends on. It contains the entire lower level interface to kernel, all the network stuff and POSIX user access stuff. It also contains a component that has no job in a C library: the dynamic executable loader. Unlike Windows on the Unix systems the C library is at the lowest level and Glibc being the default libc for Linux and making itself the default provider of the dynamic executable loader makes writing stable ABI almost impossible. Since other libraries depend on Glibc and executables depend on Glibc's dynamic loader everything is affected by the domino effect.
    - sylware 3y ago
      I agree. The elf loader should be extracted from the glibc... but there is price to pay, and it is where those guys could do their manic ABI breaking again. Some very low level interfaces will have to be defined between the external elf loader and the posix/c runtime. For the moment those interfaces are private, just look at how intimate they are about threading and TLS.
- deleted 3y ago
  [deleted]
- jcelerier 3y ago
  ?? on windows you always have to ship the libc/libc++ along with your app, as part of the VS redistributables. That's pretty much the same than static linking, the symbols are just not in the same binary.
  - pjmlp 3y ago
    Not since Universal C Runtime was created, and made part of Windows 10 systems components.
SubjectToChange 3y ago
If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel. In general glibc maintains an extremely stable ABI[1]. Forwards compatibility in both glibc and libstdc++ is something many companies depend on for their mission critical applications, and it's the entire reason Red Hat pays developers to maintain those projects. [1]: https://abi-laboratory.pro/index.php?view=timeline&l=glibc https://abi-laboratory.pro/index.php?view=timeline&l=glibc

sylware 3y ago

This has the case for 10 years with games on steam. The worst being libstdc++ ABI issues still around because many devs forget to statically link their c++ libs with -static-libstdc++. Because in windows, ABI stability is really good and then devs are used to that.

zer0zzz 3y ago
As far as I understand, Windows solves this libc++ versioning issue using the side by side cache. I guess this is a little bit like flatpack.
- sylware 3y ago
  I think there are very few c++ ABI versions on windows and it is easy to select the one you want until it is installed, they can be there side by side.
- p_l 3y ago
  Windows solves this issue by not making language runtime part of the OS libraries in a way that pollutes other libraries. That means that you can have your application linked with library A version X, and load another library that is linked with library A version Y, and so long as certain practices are followed, everything works because you're not getting cross-contamination of symbols. Meanwhile on Linux the defaults are quite different, and I can't load OpenGL ICD driver that depends on GLIBC_2.38 symbol on application that was loaded with glibc-2.37. Moreso, a lot of APIs will use malloc() and free() instead of language-independent allocator, unless the allocation comes from kernel. And no, you can't mix and match those.
  - zlg_codes 3y ago
    What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use instead of malloc and free?
    - SubjectToChange 3y ago
      I suppose they meant a "libc independent" allocator, e.g. jemalloc/tcmalloc/mimalloc/etc. Although, using such allocators comes with complications of their own: https://lwn.net/Articles/761502/ https://lwn.net/Articles/761502/
    - p_l 3y ago
      The OS provided memory allocators - HeapAlloc, its wrappers GlobalAlloc and LocalAlloc (remainders of 16bit era), VirtualAlloc (page granularity, can be compared to MAP_ANONYMOUS with mmap(), and CoTaskMemAlloc which can be shared across COM processes + their respective "free" functions. malloc() is explicitly called out in documentation as "runtime dependant". Similarly other OSes used to have memory allocation services that weren't linked in any way to a language runtime - VMS has several calls, all language independent, ranging from low-level equivalents of mmap() to malloc-alternative. And yes, a big chunk of Windows portability is that various APIs use those language-independent calls internally, and so can developer in order to avoid creating issues - and documentation promotes those language independent methods. At no point you get into situation with Windows API that you call free() on memory allocated by malloc() from a different libc. In comparison, the available language-independent APIs without using any special libraries on Linux, are to directly call mmap() and sbrk() through inline assembly (beware the glibc wrappers!).
      - account42 3y ago
        malloc in (g)libc isn't any more language dependent than HeapAlloc or VirtualAlloc. Both have a stable ABI that can be used by any language.
        3y ago
- okanat 3y ago
  Windows standard C and C++ ABI is stable since 2017. So the last 3 releases of the Visual C Compiler and C runtime hasn't changed the ABI. However Windows also has a lower level system API / ABI i.e. Win32 that's always stable all the way to Win 95. WinSXS sometimes helps for certain legacy apps too. This allows apps using different C libraries to work together. Win32 contains everything about the OS interface. Creating windows, drawing things, basic text, allocating pages from the OS, querying users, getting info about files is all stable. Win32 is the lower level of the C library. There is also a better separation of the functions in different DLLs. Win32 has multiple DLLs that has different jobs and they are mostly orthogonal. Kernel32 contains core almost system call stuff. Shell32 contains interactions with the OS shell i.e. creating windows, message boxes, triggering different UIs. The surrounding libraries like DirectX / DirectPlay / DirectWrite that are also used by the games are also part of the system libs starting from 7. They are also stable. On Linux world there is no separation of the system level libraries and normal user libraries. Glibc is just another library that one depends on. It contains the entire lower level interface to kernel, all the network stuff and POSIX user access stuff. It also contains a component that has no job in a C library: the dynamic executable loader. Unlike Windows on the Unix systems the C library is at the lowest level and Glibc being the default libc for Linux and making itself the default provider of the dynamic executable loader makes writing stable ABI almost impossible. Since other libraries depend on Glibc and executables depend on Glibc's dynamic loader everything is affected by the domino effect.
  - sylware 3y ago
    I agree. The elf loader should be extracted from the glibc... but there is price to pay, and it is where those guys could do their manic ABI breaking again. Some very low level interfaces will have to be defined between the external elf loader and the posix/c runtime. For the moment those interfaces are private, just look at how intimate they are about threading and TLS.
deleted 3y ago
[deleted]
jcelerier 3y ago
?? on windows you always have to ship the libc/libc++ along with your app, as part of the VS redistributables. That's pretty much the same than static linking, the symbols are just not in the same binary.
- pjmlp 3y ago
  Not since Universal C Runtime was created, and made part of Windows 10 systems components.

SubjectToChange 3y ago

If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel. In general glibc maintains an extremely stable ABI[1]. Forwards compatibility in both glibc and libstdc++ is something many companies depend on for their mission critical applications, and it's the entire reason Red Hat pays developers to maintain those projects. [1]: https://abi-laboratory.pro/index.php?view=timeline&l=glibc https://abi-laboratory.pro/index.php?view=timeline&l=glibc