8 ms·

GNU C Library 2.30

95 points by jrepinc 7y ago

mort96 7y ago
A lot of this sounds like great work, and the GNU project is doing great work. However, I assume I'll have to prepare for more software breaking? When 2.28 rolled around, Electron and a bunch of GNU software (which relied on glibc specific stuff which changed) broke.
- vortico 7y ago
  Software compiled against glibc links to versioned symbols, which are backwards compatible in ABI and behavior. I'm unsure of the reason you experienced breaking software when upgrading your glibc version.
  - mort96 7y ago
    The GNU software which broke just didn't compile (with no upstream fix available for a long time, which I found incredible; I had to go find arch linux' repos' patch and apply that whenever I wanted to compile GNU build tools). The electron thing was apparently an LLVM linker thing according to your sibling comment. EDIT: the m4 patch in question: https://git.archlinux.org/svntogit/packages.git/tree/trunk/m4-1.4.18-glibc-change-work-around.patch?h=packages/m4 https://git.archlinux.org/svntogit/packages.git/tree/trunk/m... - apparently they still use it.
    - shakna 7y ago
      > FIXME: Do not rely on glibc internals. Seems that's less of a glibc breaking compatibility, and more developers relying on something outside of the guaranteed API.
      - mort96 7y ago
        I mean, it's GNU M4. It's at the core of GNU's build system. It's GNU developers depending on glibc internals. I'd be with you if it was just some random project, but it's pretty bad of an update to glibc to break the GNU toolchain.
- berti 7y ago
  glibc goes to some length to ensure software linked against an older release will always run unmodified when a newer release is loaded so your comment surprised me a bit. Turns out it was actually an LLVM linker bug [0], fixed in Electron when they moved to building with a newer version of LLVM [1]. [0] https://github.com/electron/electron/issues/13972#issuecomment-411532741 https://github.com/electron/electron/issues/13972#issuecomme... [1] https://github.com/electron/electron/pull/13988 https://github.com/electron/electron/pull/13988
fluffything 7y ago
> * The twalk_r function has been added. It is similar to the existing twalk function, but it passes an additional caller-supplied argument to the callback function. I thought this was standard practice for designing C APIs taking callbacks. > * The Linux-specific <sys/sysctl.h> header and the sysctl function have been deprecated and will be removed from a future version of glibc. Application should directly access /proc instead. For obtaining random bits, the getentropy function can be used. That's gonna break the world, a lot of code includes that header and uses the sysctl function.
- WillDaSilva 7y ago
  Well on the bright side it's perfectly reasonable for the function to exist in a perpetual state of deprecation. Let's hope they don't do anything rash.
  - ronsor 7y ago
    If they do, Linus will probably scream at them for breaking compatibility. (Even if this isn't the kernel)
    - jabl 7y ago
      This is a glibc wrapper for the sysctl system call, which has been deprecated since forever in the kernel, is compiled in only if an option is specified (major distros don't enable it), and is likely to be removed completely at some point. Currently trying to use it, even if enabled, generates a warning in the kernel log. http://man7.org/linux/man-pages/man2/sysctl.2.html http://man7.org/linux/man-pages/man2/sysctl.2.html
- kevin_thibedeau 7y ago
  > I thought this was standard practice for designing C APIs taking callbacks. This is to supplant non-reentrant shared state for node depth. Same as strtok() -> strtok_r(). Doing this with the generic closure arg is just a bonus since the callback is already present.
zoobab 7y ago
Static linking works now? Or I have to use Musl to have this feature working?
- pragmaticlurker 7y ago
  static linking works also with glibc, AFAIK (using it)
  - jabl 7y ago
    IIRC NSS (/etc/nsswitch.conf etc.) needs dynamic linking for anything beyond the basic files backend. But, again IIRC, musl has never supported NSS anyway so that's kind of a moot point.
    - jcelerier 7y ago
      > IIRC NSS (/etc/nsswitch.conf etc.) needs dynamic linking for anything beyond the basic files backend. But, again IIRC, musl has never supported NSS anyway so that's kind of a moot point. I frankly have never ever ever seen anyone actually configure NSS outside of the defaults.
      - georgyo 7y ago
        You have never been in an organization that has used ldap or other user backends then. However even the defaults on Debian and Centos are affected here, as it means that the dynamic user/host stuff in systemd also won't get picked up when something doesn't read nsswitch
      - arianvanp 7y ago
        It's needed for Bonjour/avahi/mdns. It's also needed for systemd dynamic users. If you have either of those, you will have an /etc/nsswitch.conf that requires dynamic linking :)
pascal_cuoq 7y ago
> * Memory allocation functions malloc, calloc, realloc, reallocarray, valloc, pvalloc, memalign, and posix_memalign fail now with total object size larger than PTRDIFF_MAX. This is to avoid potential undefined behavior with pointer subtraction within the allocated object, where results might overflow the ptrdiff_t type. I did not think they would take this decision so soon, but it is, in my opinion, the right decision to take. There will be complaints from users of memory-heavy programs running on 32-bit platforms though. For context, this blog post shows how things break when allocation functions are allowed to create blocks of more than PTRDIFF_MAX: https://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/ https://trust-in-soft.com/objects-larger-than-ptrdiff_max-by...
- jabl 7y ago
  Absolutely, this is the right thing to do. If one needs to allocate more than 2 GB in a single allocation, time to move to 64-bit.
  - Iwan-Zotow 7y ago
    > If one needs to allocate more than 2 GB in a single allocation, time to move to 64-bit. time to move to (anonymus) mmap - it still has size_t as type for the size argument
- hoseja 7y ago
  That first clang listing was hilarious.
- jandrese 7y ago
  > There will be complaints from users of memory-heavy programs running on 32-bit platforms though. I would think this would be a small one of many complaints such users would have on a daily basis.
- ajross 7y ago
  > There will be complaints from users of memory-heavy programs running on 32-bit platforms though In all of recorded history, has a malloc() call for more than 2GB ever actually succeeded anywhere? Most OSes on such platforms never supported any more than that amount of addressible memory in a user process at all. This is fine. Honestly it's seems like mostly pedantry on modern systems, but it's clearly correct.
e12e 7y ago
Anyone able to expand on: "The dynamic linker accepts the --preload argument to preload shared objects, in addition to the LD_PRELOAD environment variable."? Does one ever invoke the dynamic linker directly? Why? How?
- gdamjan1 7y ago
  yes, you can. the linker loader is the default executable for all ELF binaries
- iso-8859-1 7y ago
  $ /lib64/ld-linux-x86-64.so.2 /bin/true --version true (GNU coreutils) 8.28 [...] If you run it without arguments it will tell you usage.
  - e12e 7y ago
    Ah, yes of course. I actually do this often to look for missing runtime dependencies. I hadn't thought about preload in that context - or ldd as a way to run executables "by hand".
- yrro 7y ago
  IIRC it lets you get around the noexec flag on a mount.
metalforever 7y ago
How is the support for the 68k in this release?
yrro 7y ago
Whoa, a gettid wrapper? What changed the maintainers' minds on making that available?

95 points by jrepinc 7y ago

A lot of this sounds like great work, and the GNU project is doing great work. However, I assume I'll have to prepare for more software breaking? When 2.28 rolled around, Electron and a bunch of GNU software (which relied on glibc specific stuff which changed) broke.

vortico 7y ago
Software compiled against glibc links to versioned symbols, which are backwards compatible in ABI and behavior. I'm unsure of the reason you experienced breaking software when upgrading your glibc version.
- mort96 7y ago
  The GNU software which broke just didn't compile (with no upstream fix available for a long time, which I found incredible; I had to go find arch linux' repos' patch and apply that whenever I wanted to compile GNU build tools). The electron thing was apparently an LLVM linker thing according to your sibling comment. EDIT: the m4 patch in question: https://git.archlinux.org/svntogit/packages.git/tree/trunk/m4-1.4.18-glibc-change-work-around.patch?h=packages/m4 https://git.archlinux.org/svntogit/packages.git/tree/trunk/m... - apparently they still use it.
  - shakna 7y ago
    > FIXME: Do not rely on glibc internals. Seems that's less of a glibc breaking compatibility, and more developers relying on something outside of the guaranteed API.
    - mort96 7y ago
      I mean, it's GNU M4. It's at the core of GNU's build system. It's GNU developers depending on glibc internals. I'd be with you if it was just some random project, but it's pretty bad of an update to glibc to break the GNU toolchain.
berti 7y ago
glibc goes to some length to ensure software linked against an older release will always run unmodified when a newer release is loaded so your comment surprised me a bit. Turns out it was actually an LLVM linker bug [0], fixed in Electron when they moved to building with a newer version of LLVM [1]. [0] https://github.com/electron/electron/issues/13972#issuecomment-411532741 https://github.com/electron/electron/issues/13972#issuecomme... [1] https://github.com/electron/electron/pull/13988 https://github.com/electron/electron/pull/13988

fluffything 7y ago

> * The twalk_r function has been added. It is similar to the existing twalk function, but it passes an additional caller-supplied argument to the callback function. I thought this was standard practice for designing C APIs taking callbacks. > * The Linux-specific <sys/sysctl.h> header and the sysctl function have been deprecated and will be removed from a future version of glibc. Application should directly access /proc instead. For obtaining random bits, the getentropy function can be used. That's gonna break the world, a lot of code includes that header and uses the sysctl function.

WillDaSilva 7y ago
Well on the bright side it's perfectly reasonable for the function to exist in a perpetual state of deprecation. Let's hope they don't do anything rash.
- ronsor 7y ago
  If they do, Linus will probably scream at them for breaking compatibility. (Even if this isn't the kernel)
  - jabl 7y ago
    This is a glibc wrapper for the sysctl system call, which has been deprecated since forever in the kernel, is compiled in only if an option is specified (major distros don't enable it), and is likely to be removed completely at some point. Currently trying to use it, even if enabled, generates a warning in the kernel log. http://man7.org/linux/man-pages/man2/sysctl.2.html http://man7.org/linux/man-pages/man2/sysctl.2.html
kevin_thibedeau 7y ago
> I thought this was standard practice for designing C APIs taking callbacks. This is to supplant non-reentrant shared state for node depth. Same as strtok() -> strtok_r(). Doing this with the generic closure arg is just a bonus since the callback is already present.

zoobab 7y ago

Static linking works now? Or I have to use Musl to have this feature working?

pragmaticlurker 7y ago
static linking works also with glibc, AFAIK (using it)
- jabl 7y ago
  IIRC NSS (/etc/nsswitch.conf etc.) needs dynamic linking for anything beyond the basic files backend. But, again IIRC, musl has never supported NSS anyway so that's kind of a moot point.
  - jcelerier 7y ago
    > IIRC NSS (/etc/nsswitch.conf etc.) needs dynamic linking for anything beyond the basic files backend. But, again IIRC, musl has never supported NSS anyway so that's kind of a moot point. I frankly have never ever ever seen anyone actually configure NSS outside of the defaults.
    - georgyo 7y ago
      You have never been in an organization that has used ldap or other user backends then. However even the defaults on Debian and Centos are affected here, as it means that the dynamic user/host stuff in systemd also won't get picked up when something doesn't read nsswitch
    - arianvanp 7y ago
      It's needed for Bonjour/avahi/mdns. It's also needed for systemd dynamic users. If you have either of those, you will have an /etc/nsswitch.conf that requires dynamic linking :)

pascal_cuoq 7y ago

> * Memory allocation functions malloc, calloc, realloc, reallocarray, valloc, pvalloc, memalign, and posix_memalign fail now with total object size larger than PTRDIFF_MAX. This is to avoid potential undefined behavior with pointer subtraction within the allocated object, where results might overflow the ptrdiff_t type. I did not think they would take this decision so soon, but it is, in my opinion, the right decision to take. There will be complaints from users of memory-heavy programs running on 32-bit platforms though. For context, this blog post shows how things break when allocation functions are allowed to create blocks of more than PTRDIFF_MAX: https://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/ https://trust-in-soft.com/objects-larger-than-ptrdiff_max-by...

jabl 7y ago
Absolutely, this is the right thing to do. If one needs to allocate more than 2 GB in a single allocation, time to move to 64-bit.
- Iwan-Zotow 7y ago
  > If one needs to allocate more than 2 GB in a single allocation, time to move to 64-bit. time to move to (anonymus) mmap - it still has size_t as type for the size argument
hoseja 7y ago
That first clang listing was hilarious.
jandrese 7y ago
> There will be complaints from users of memory-heavy programs running on 32-bit platforms though. I would think this would be a small one of many complaints such users would have on a daily basis.
ajross 7y ago
> There will be complaints from users of memory-heavy programs running on 32-bit platforms though In all of recorded history, has a malloc() call for more than 2GB ever actually succeeded anywhere? Most OSes on such platforms never supported any more than that amount of addressible memory in a user process at all. This is fine. Honestly it's seems like mostly pedantry on modern systems, but it's clearly correct.

e12e 7y ago

Anyone able to expand on: "The dynamic linker accepts the --preload argument to preload shared objects, in addition to the LD_PRELOAD environment variable."? Does one ever invoke the dynamic linker directly? Why? How?

gdamjan1 7y ago
yes, you can. the linker loader is the default executable for all ELF binaries
iso-8859-1 7y ago
$ /lib64/ld-linux-x86-64.so.2 /bin/true --version true (GNU coreutils) 8.28 [...] If you run it without arguments it will tell you usage.
- e12e 7y ago
  Ah, yes of course. I actually do this often to look for missing runtime dependencies. I hadn't thought about preload in that context - or ldd as a way to run executables "by hand".
yrro 7y ago
IIRC it lets you get around the noexec flag on a mount.

metalforever 7y ago

How is the support for the 68k in this release?

yrro 7y ago

Whoa, a gettid wrapper? What changed the maintainers' minds on making that available?