|
|
Log in / Subscribe / Register

GNU C Library 2.31 released

The GNU libc 2.31 release is out. Significant changes include some initial C2X standard support, some DNS stub resolver changes, a new pthread_clockjoin_np() POSIX threads extension, a number of changes to time-related functions, and more.


From:  Siddhesh Poyarekar <siddhesh-AT-sourceware.org>
To:  "info-gnu-AT-gnu.org" <info-gnu-AT-gnu.org>
Subject:  The GNU C Library version 2.31 is now available
Date:  Sat, 1 Feb 2020 18:42:22 +0530
Message-ID:  <fcfe2e0b-d90b-c73a-0d03-e56a50e98e21@sourceware.org>
Archive-link:  Article

The GNU C Library
=================

The GNU C Library version 2.31 is now available.

The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library.  It follows all relevant
standards including ISO C11 and POSIX.1-2017.  It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library webpage is at http://www.gnu.org/software/libc/

Packages for the 2.31 release may be downloaded from:
        http://ftpmirror.gnu.org/libc/
        http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

NEWS for version 2.31
=====================

Major new features:

* The GNU C Library now supports a feature test macro _ISOC2X_SOURCE
  to enable features from the draft ISO C2X standard.  Only some
  features from this draft standard are supported by the GNU C
  Library, and as the draft is under active development, the set of
  features enabled by this macro is liable to change.  Features from
  C2X are also enabled by _GNU_SOURCE, or by compiling with "gcc
  -std=gnu2x".

* The <math.h> functions that round their results to a narrower type
  now have corresponding type-generic macros in <tgmath.h>, as defined
  in TS 18661-1:2014 and TS 18661-3:2015 as amended by the resolution
  of Clarification Request 13 to TS 18661-3.

* The function pthread_clockjoin_np has been added, enabling join with
  a terminated thread with a specific clock.  It allows waiting
  against CLOCK_MONOTONIC and CLOCK_REALTIME.  This function is a GNU
  extension.

* New locale added: mnw_MM (Mon language spoken in Myanmar).

* The DNS stub resolver will optionally send the AD (authenticated
  data) bit in queries if the trust-ad option is set via the options
  directive in /etc/resolv.conf (or if RES_TRUSTAD is set in
  _res.options).  In this mode, the AD bit, as provided by the name
  server, is available to applications which call res_search and
  related functions.  In the default mode, the AD bit is not set in
  queries, and it is automatically cleared in responses, indicating a
  lack of DNSSEC validation.  (Therefore, the name servers and the
  network path to them are treated as untrusted.)

Deprecated and removed features, and other changes affecting
compatibility:

* The totalorder and totalordermag functions, and the corresponding
  functions for other floating-point types, now take pointer arguments
  to avoid signaling NaNs possibly being converted to quiet NaNs in
  argument passing.  This is in accordance with the resolution of
  Clarification Request 25 to TS 18661-1, as applied for C2X.
  Existing binaries that pass floating-point arguments directly will
  continue to work.

* The obsolete function stime is no longer available to newly linked
  binaries, and its declaration has been removed from <time.h>.
  Programs that set the system time should use clock_settime instead.

* We plan to remove the obsolete function ftime, and the header
  <sys/timeb.h>, in a future version of glibc.  In this release, the
  header still exists but calling ftime will cause a compiler warning.
  All programs should use gettimeofday or clock_gettime instead.

* The gettimeofday function no longer reports information about a
  system-wide time zone.  This 4.2-BSD-era feature has been deprecated
  for many years, as it cannot handle the full complexity of the
  world's timezones, but hitherto we have supported it on a
  best-effort basis.  Changes required to support 64-bit time_t on
  32-bit architectures have made this no longer practical.

  As of this release, callers of gettimeofday with a non-null 'tzp'
  argument should expect to receive a 'struct timezone' whose
  tz_minuteswest and tz_dsttime fields are zero.  (For efficiency
  reasons, this does not always happen on a few Linux-based ports.
  This will be corrected in a future release.)

  All callers should supply a null pointer for the 'tzp' argument to
  gettimeofday.  For accurate information about the time zone
  associated with the current time, use the localtime function.

  gettimeofday itself is obsolescent according to POSIX.  We have no
  plans to remove access to this function, but portable programs
  should consider using clock_gettime instead.

* The settimeofday function can still be used to set a system-wide
  time zone when the operating system supports it.  This is because
  the Linux kernel reused the API, on some architectures, to describe
  a system-wide time-zone-like offset between the software clock
  maintained by the kernel, and the "RTC" clock that keeps time when
  the system is shut down.

  However, to reduce the odds of this offset being set by accident,
  settimeofday can no longer be used to set the time and the offset
  simultaneously.  If both of its two arguments are non-null, the call
  will fail (setting errno to EINVAL).

  Callers attempting to set this offset should also be prepared for
  the call to fail and set errno to ENOSYS; this already happens on
  the Hurd and on some Linux architectures.  The Linux kernel
  maintainers are discussing a more principled replacement for the
  reused API.  After a replacement becomes available, we will change
  settimeofday to fail with ENOSYS on all platforms when its 'tzp'
  argument is not a null pointer.

  settimeofday itself is obsolescent according to POSIX.  Programs
  that set the system time should use clock_settime and/or the adjtime
  family of functions instead.  We may cease to make settimeofday
  available to newly linked binaries after there is a replacement for
  Linux's time-zone-like offset API.

* SPARC ISA v7 is no longer supported.  v8 is still supported, but
  only if the optional CAS instruction is implemented (for instance,
  LEON processors are still supported, but SuperSPARC processors are
  not).

  As the oldest 64-bit SPARC ISA is v9, this only affects 32-bit
  configurations.

* If a lazy binding failure happens during dlopen, during the
  execution of an ELF constructor, the process is now terminated.
  Previously, the dynamic loader would return NULL from dlopen, with
  the lazy binding error captured in a dlerror message.  In general,
  this is unsafe because resetting the stack in an arbitrary function
  call is not possible.

* For MIPS hard-float ABIs, the GNU C Library will be configured to
  need an executable stack unless explicitly configured at build time
  to require minimum kernel version 4.8 or newer.  This is because
  executing floating-point branches on a non-executable stack on Linux
  kernels prior to 4.8 can lead to application crashes for some MIPS
  configurations. While currently PT_GNU_STACK is not widely used on
  MIPS, future releases of GCC are expected to enable non-executable
  stack by default with PT_GNU_STACK by default and is thus likely to
  trigger a crash on older kernels.

  The GNU C Library can be built with --enable-kernel=4.8.0 in order
  to keep a non-executable stack while dropping support for older
  kernels.

* System call wrappers for time system calls now use the new time64
  system calls when available. On 32-bit targets, these wrappers
  attempt to call the new system calls first and fall back to the
  older 32-bit time system calls if they are not present.  This may
  cause issues in environments that cannot handle unsupported system
  calls gracefully by returning -ENOSYS. Seccomp sandboxes are
  affected by this issue.

Changes to build and runtime requirements:

* It is no longer necessary to have recent Linux kernel headers to
  build working (non-stub) system call wrappers on all architectures
  except 64-bit RISC-V.  64-bit RISC-V requires a minimum kernel
  headers version of 5.0.

* The ChangeLog file is no longer present in the toplevel directory of
  the source tree.  ChangeLog files are located in the ChangeLog.old
  directory as ChangeLog.N where the highest N has the latest entries.

Security related changes:

  CVE-2019-19126: ld.so failed to ignore the LD_PREFER_MAP_32BIT_EXEC
  environment variable during program execution after a security
  transition, allowing local attackers to restrict the possible
  mapping addresses for loaded libraries and thus bypass ASLR for a
  setuid program.  Reported by Marcin Kościelnicki.

The following bugs are resolved with this release:

  [12031] localedata: iconv -t ascii//translit with Greek characters
  [15813] libc: Multiple issues in __gen_tempname
  [17726] libc: [arm, sparc] profil_counter should be compat symbol
  [18231] libc: ipc_perm struct's mode member has wrong type in
    sys/ipc.h
  [19767] libc: vdso is not used with static linking
  [19903] hurd: Shared mappings not being inherited by children
    processes
  [20358] network: RES_USE_DNSSEC sets DO; should also have a way to set
    AD
  [20839] dynamic-link: Incomplete rollback of dynamic linker state on
    linking failure
  [23132] localedata: Missing transliterations in Miscellaneous
    Mathematical Symbols-A/B Unicode blocks
  [23518] libc: Eliminate __libc_utmp_jump_table
  [24026] malloc: malloc_info() returns wrong numbers
  [24054] localedata: Many locales are missing date_fmt
  [24214] dynamic-link: user defined ifunc resolvers may run in ldd mode
  [24304] dynamic-link: Lazy binding failure during ELF
    constructors/destructors is not fatal
  [24376] libc: RISC-V symbol size confusion with _start
  [24682] localedata: zh_CN first weekday should be Monday per GB/T
    7408-2005
  [24824] libc: test-in-container does not install charmap files
    compatible with localedef
  [24844] regex: regex bad pointer / leakage if malloc fails
  [24867] malloc: Unintended malloc_info formatting changes
  [24879] libc: login: utmp alarm timer can arrive after lock
    acquisition
  [24880] libc: login: utmp implementation uses struct flock with
    fcntl64
  [24882] libc: login: pututline uses potentially outdated cache
  [24899] libc: Missing nonstring attributes in <utmp.h>, <utmpx.h>
  [24902] libc: login: Repeating pututxline on EINTR/EAGAIN causes stale
    utmp entries
  [24916] dynamic-link: [MIPS] Highest EI_ABIVERSION value not raised to
    ABSOLUTE ABI
  [24930] dynamic-link: dlopen of PIE executable can result in
    _dl_allocate_tls_init assertion failure
  [24950] localedata: Top-of-tree glibc does not build with top-of-tree
    GCC (stringop-overflow error)
  [24959] time: librt IFUNC resolvers for clock_gettime and clock_*
    functions other  can lead to crashes
  [24967] libc: jemalloc static linking causes runtime failure
  [24986] libc: alpha: new getegid, geteuid and getppid syscalls used
    unconditionally
  [25035] libc: sbrk() failure handled poorly in tunables_strdup
  [25087] dynamic-link: ldconfig mishandles unusual .dynstr placement
  [25097] libc: new -Warray-bounds with GCC 10
  [25112] dynamic-link: dlopen must not make new objects accessible when
    it still can fail with an error
  [25139] localedata: Please add the new mnw_MM locale
  [25149] regex: Array bounds violation in proceed_next_node
  [25157] dynamic-link: Audit cookie for the dynamic loader is not
    initialized correctly
  [25189] libc: glibc's __glibc_has_include causes issues with clang
    -frewrite-includes
  [25194] malloc: malloc.c: do_set_mxfast incorrectly casts the mallopt
    value to an unsigned
  [25204] dynamic-link: LD_PREFER_MAP_32BIT_EXEC not ignored in setuid
    binaries (CVE-2019-19126)
  [25225] libc: ld.so fails to link on x86 if GCC defaults to -fcf-
    protection
  [25226] string: strstr: Invalid result if needle crosses page on s390-
    z15 ifunc variant.
  [25232] string: <string.h> does not enable const correctness for
    strchr et al. for Clang++
  [25233] localedata: Consider "." as the thousands separator for sl_SI
    (Slovenian)
  [25241] nptl: __SIZEOF_PTHREAD_MUTEX_T defined twice for x86
  [25251] build: Failure to run tests when CFLAGS contains -DNDEBUG.
  [25271] libc: undeclared identifier PTHREAD_MUTEX_DEFAULT when
    compiling with -std=c11
  [25323] localedata: km_KH: d_t_fmt contains "m" instead of "%M"
  [25324] localedata: lv_LV: d_t_fmt contains suspicious words in the
    time part
  [25396] dynamic-link: Failing dlopen can leave behind dangling GL
    (dl_initfirst) link map pointer
  [25401] malloc: pvalloc must not have __attribute_alloc_size__
  [25423] libc: Array overflow in backtrace on powerpc
  [25425] network: Missing call to __resolv_context_put in
    getaddrinfo.c:gethosts

Release Notes
=============

https://sourceware.org/glibc/wiki/Release/2.31

Contributors
============

This release was made possible by the contributions of many people.
The maintainers are grateful to everyone who has contributed changes
or bug reports.  These include:

Adhemerval Zanella
Alexandra Hájková
Alistair Francis
Andreas Schwab
Andrew Eggenberger
Arjun Shankar
Aurelien Jarno
Carlos O'Donell
Chung-Lin Tang
DJ Delorie
Dmitry V. Levin
Dragan Mladjenovic
Egor Kobylkin
Emilio Cobos Álvarez
Emilio Pozuelo Monfort
Feng Xue
Florian Weimer
Gabriel F. T. Gomes
Gustavo Romero
H.J. Lu
Ian Kent
James Clarke
Jeremie Koenig
John David Anglin
Joseph Myers
Kamlesh Kumar
Krzysztof Koch
Leandro Pereira
Lucas A. M. Magalhaes
Lukasz Majewski
Marcin Kościelnicki
Matheus Castanho
Mihailo Stojanovic
Mike Crowe
Mike FABIAN
Niklas Hambüchen
Paul A. Clarke
Paul Eggert
Petr Vorel
Rafal Luzynski
Rafał Lużyński
Rajalakshmi Srinivasaraghavan
Raoni Fassina Firmino
Richard Braun
Samuel Thibault
Sandra Loosemore
Siddhesh Poyarekar
Stefan Liebler
Svante Signell
Szabolcs Nagy
Talachan Mon
Thomas Schwinge
Tim Rühsen
Tulio Magno Quites Machado Filho
Wilco Dijkstra
Xuelei Zhang
Zack Weinberg
liqingqing

-- 
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.


to post comments

GNU C Library 2.31 released

Posted Feb 1, 2020 17:51 UTC (Sat) by ceplm (subscriber, #41334) [Link] (13 responses)

It would be helpful if the author of the release notes looked through the list of contributors before publishing it:

Rafal Luzynski
Rafał Lużyński

GNU C Library 2.31 released

Posted Feb 2, 2020 1:08 UTC (Sun) by siddhesh (guest, #64914) [Link] (12 responses)

I did look through and I missed it. Oops :/

GNU C Library 2.31 released

Posted Feb 2, 2020 5:53 UTC (Sun) by ceplm (subscriber, #41334) [Link] (11 responses)

Oh well. Bloody Slavs with their weird names (I am Czech, so I know what I am talking about)! Matěj

GNU C Library 2.31 released

Posted Feb 2, 2020 9:25 UTC (Sun) by Wol (subscriber, #4433) [Link]

Why are you weird? It's those Americans with their weird fixation that they (and the world) speak English! (Hint - it's the ENGLISH that speak English)

:-) :-)

Cheers,
Wol

GNU C Library 2.31 released

Posted Feb 2, 2020 9:43 UTC (Sun) by lkundrak (subscriber, #43452) [Link] (7 responses)

truly yours,

Grzegorz Brzęczyszczykiewicz.

GNU C Library 2.31 released

Posted Feb 2, 2020 20:19 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Polish is one language that REALLY should have gotten its own alphabet or at least diacritical signs instead of abusing Latin digraphs.

GNU C Library 2.31 released

Posted Feb 3, 2020 13:23 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (2 responses)

Gřegoř Břečyščykiewič.

not sure if better :)

GNU C Library 2.31 released

Posted Feb 3, 2020 17:31 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Honestly, it's much more readable.

GNU C Library 2.31 released

Posted Feb 5, 2020 17:35 UTC (Wed) by jezuch (subscriber, #52988) [Link]

Don't worry, you get used to it. My first name is Krzysztof and even Americans stop butchering it after a while :)

GNU C Library 2.31 released

Posted Feb 5, 2020 17:38 UTC (Wed) by jezuch (subscriber, #52988) [Link] (2 responses)

(Besides, we do have diacritics in ą ć ę ł ń ó ś ź ż, but I guess you knew that.)

GNU C Library 2.31 released

Posted Feb 5, 2020 17:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Yeah, but not enough. Digraphs in Polish are really overused to death.

GNU C Library 2.31 released

Posted Feb 7, 2020 11:43 UTC (Fri) by NAR (subscriber, #1313) [Link]

Digraphs have the advantage that they can be typed even without a localised keyboard. New characters - that's more complicated. I can (almost) type Brzęczyszczykiewicz, but has no chance to type Břečyščykiewič. I could use r instead of ř, etc, and might work in some (even most) cases, but you really don't want to type Szar instead of Szár when you're talking about the village :-)

GNU C Library 2.31 released

Posted Feb 2, 2020 20:05 UTC (Sun) by willy (subscriber, #9762) [Link] (1 responses)

Wait, you're Czech Matěj? I feel like you must be a phenomenal chess player ... 😜

GNU C Library 2.31 released

Posted Feb 2, 2020 22:28 UTC (Sun) by ceplm (subscriber, #41334) [Link]

Is it a Czech-check joke? *groan*

And no I am not filthy right either, there are not that many cheques around (actually, there are almost none, with went from banknotes straight to paperless economy without going through cheques and true credit cards).

GNU C Library 2.31 released

Posted Feb 3, 2020 3:28 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (34 responses)

"The obsolete function stime is no longer available to newly linked binaries, and its declaration has been removed from <time.h>."

Look at the man page*. There's no mention of it being deprecated, or even that there's better choices. Yes, GNU loves its Info pages. The Info page for GLIBC 2.30** says

> settimeofday is a newer function which sets the system clock to better than one second precision. settimeofday is generally a better choice than stime.

Better, but certainly not deprecation. It doesn't even say "settimeofday is a better choice". A program using stime compiles and links without warning.

So even if you read the manual for the latest version, there was no warning that stime was going to get deleted, and certainly not in the most helpful sense, where a warning is issued when you attempt to compile and link a program using the function. Surely such a core library should hold itself to a higher standard.

(No, I wasn't using it, and I don't know that anyone was using it. The standards of giving time for deprecation still apply.)

* http://man7.org/linux/man-pages/man2/stime.2.html This is what shows on a Debian Unstable system updated last week, too.
** http://web.archive.org/web/20190926065159/https://www.gnu... GNU has updated the info page on its site to version 2.31, but this is for the version 2.30, archived September of 2019.

GNU C Library 2.31 released

Posted Feb 3, 2020 12:53 UTC (Mon) by BirAdam (guest, #132170) [Link] (31 responses)

Is this behavior normal for the GNU C developers (to deprecate/remove without warning)?

Saying one thing is “generally better” than another is absolutely not a warning of pending removal.

GNU C Library 2.31 released

Posted Feb 3, 2020 16:18 UTC (Mon) by HelloWorld (guest, #56129) [Link] (30 responses)

> Is this behavior normal for the GNU C developers (to deprecate/remove without warning)?
It wasn't removed, it's just not available to newly linked binaries. Existing binaries will still work.

GNU C Library 2.31 released

Posted Feb 3, 2020 16:57 UTC (Mon) by rschroev (subscriber, #4164) [Link] (16 responses)

>> Is this behavior normal for the GNU C developers (to deprecate/remove without warning)?

> It wasn't removed, it's just not available to newly linked binaries. Existing binaries will still work.

But existing sources (that use stime) won't compile anymore. That's a pretty bold move. Let's hope they don't start doing the same with functions that are more frequently used (assuming here that there aren't all that much programs that set the time).

GNU C Library 2.31 released

Posted Feb 3, 2020 20:44 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (15 responses)

Don't worry, it is already sorted out by distributions. That's distros role - find new problems, fix them and submit patch upstream. Or at least notice upstream there's something needs patching.
Recent changes, like this stime() or GCC10's -fno-common, have been already handled by Fedora packagers.

GNU C Library 2.31 released

Posted Feb 3, 2020 22:39 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (14 responses)

"Don't worry, you don't actually need to see or use the source." is against the FSF philosophy. Distributions don't actually have all software in them, even the huge ones like Debian and Fedora; the exclusions may be weird and unusual enough not to be packaged, it may be some package you downloaded from Freshmeat a couple decades ago, or it may be something you wrote yourself.

And I'm not sure maintainers of distributions agree. I'm sure they would rather get to upgrade to Glibc 2.31 and dump out a number of bugs on various packages, telling them Glibc 2.32 is coming and these things need to be fixed, rather than Glibc 2.31 just breaking things. I suppose if you're like Fedora and have someone on the inside who can give advanced warning, that's fine, but Arch Linux deserves that time too.

GNU C Library 2.31 released

Posted Feb 3, 2020 23:01 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (13 responses)

>"Don't worry, you don't actually need to see or use the source."

That's a strawman. Not a real quote.

>I suppose if you're like Fedora and have someone on the inside who can give advanced warning, that's fine, but Arch Linux deserves that time too.

Fedora packagers just read the gcc documentation associated with said changes. No insider information necessary.

GNU C Library 2.31 released

Posted Feb 4, 2020 8:37 UTC (Tue) by dvdeug (subscriber, #10998) [Link] (12 responses)

It's hyperbole. The point stands; saying that distributions will take care of it implies that we should all be using neat binary distributions that someone else handles.

> Fedora packagers just read the gcc documentation associated with said changes. No insider information necessary.

That still makes each change of version a dramatic matter; instead of knowing that something will need fixing in the future, it's has to be fixed now, before the new version of GCC can be deployed. That's why GCC doesn't usually do this.

Note that this thread and article is about the GNU C library, not GCC. GCC has major versions that have a minor fix numbers, and continue to support old versions for sometime; the latest version of GCC is 9, with 9.1 released on May 3, 2019 and 9.2 released on August 12, 2019, and the latest version of GCC 7 is GCC 7.5, released November 14, 2019. GCC 7.5 was released two years after GCC 7.1, meaning long term releases are not compelled to upgrade to completely new versions.

On the other hand, the GNU C library has been on version 2 for 20 years now, and releases a new "minor" version every six months. You get no bug fix releases, and it's much harder to mix versions with libc, so every six months, a distributor has to do a full system audit to find things like this before upgrading the system glibc. Giving a version where things were deprecated would mean that a distributor could upgrade glibc and have six months to figure out how to fix all the problems. Otherwise, bug fixes are likely to get backported to avoid breaking stuff, and that's always problematic.

Because of the release pattern, giving no warning of deprecation for glibc is much worse than for GCC.

GNU C Library 2.31 released

Posted Feb 4, 2020 15:37 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

>It's hyperbole. The point stands; saying that distributions will take care of it implies that we should all be using neat binary distributions that someone else handles.

Yes, stating the point directly is better than using a fake quote.

> That still makes each change of version a dramatic matter

I don't think it is all that dramatic really. Regardless of that, I don't think maintaining compatibility is fundamental to the definition of free software. If it was, openssl would have to be considered non-free and that isn't the case, clearly. Compatibility is nicer to maintain for users and less so for maintainers. That's just a tradeoff

GNU C Library 2.31 released

Posted Feb 4, 2020 22:33 UTC (Tue) by dvdeug (subscriber, #10998) [Link] (10 responses)

I'm sorry it annoys you so, but it's not a fake quote; repeating something back in the way it you heard it is a frequent rhetorical flourish, and when there's no chance anyone is confused by it, it is absolutely okay.

> I don't think maintaining compatibility is fundamental to the definition of free software.

The point was that dismissing concerns by saying that only certain privileged users need worry about issues with the source is antithetical to the definition of free software. Note that you've stated your point directly, and I still feel annoyed that you're fundamentally misstating what I said.

GNU C Library 2.31 released

Posted Feb 4, 2020 23:24 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

>when there's no chance anyone is confused by it, it is absolutely okay.

I was certainly confused by the use of quotation marks for something that wasn't in the content you replied to and had to double check to make sure I wasn't missing something

>The point was that dismissing concerns by saying that only certain privileged users need worry about issues with the source is antithetical to the definition of free software.

I don't buy that either. Talking about "insider" access streches things as well. OP was simply noting that distributions typically take care of integration issues. Users typically use software sourced from distributions. If you must use older source, often you need to use older version of build tooling

>Note that you've stated your point directly, and I still feel annoyed that you're fundamentally misstating what I said.

I am not intentionally mistating your point FYI. I stated it as I understood it

GNU C Library 2.31 released

Posted Feb 5, 2020 6:24 UTC (Wed) by dvdeug (subscriber, #10998) [Link] (2 responses)

> I was certainly confused by the use of quotation marks for something that wasn't in the content you replied to
...
> Talking about "insider" access streches things as well.

Can I point out that I never said "insider"? If you want to insist that quotation marks are to be used only to precisely quote someone, you might want to try and do that.

> Talking about "insider" access streches things as well. OP was simply noting that distributions typically take care of integration issues.

OP said that Fedora had already taken care of it; if they've already checked all their packages for the problem, it's probably because they have a developer working on glibc who was testing early releases and knew that this change was happening. There's certainly a difference between Fedora and most distributions in the amount of manpower available.

> Users typically use software sourced from distributions.

Users, in a free software world, write their own code and sometimes even create their own distributions. Certainly, on this website, you can not expect that everyone here is just using stuff canned from the distributions. I'd say virtually everyone here has some code on their system that they wrote and would need to personally keep working.

GNU C Library 2.31 released

Posted Feb 5, 2020 9:35 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

Fedora was not fixed by developer working on glibc. It was fixed by maintainers. Process was smooth thanks to automatic rebuilds filling bugs against packages FTBFS. There were also questions on fedora-devel list. Both bugs and questions were commented on by people knowledgeable, providing input on how to proceed with fixing. Thanks to this, regular maintainers like myself were able to patch the code.
I assume every distribution have some "development" branch were new issues are fixed in the above described manner.

And no, you are not forced to use binaries only. But keep in mind, if you want to replicate work done by distribution - namely providing source converted to working, integrated binaries - you have to *replicate work done by distribution*. Including fixing and patching.
Don't worry, you are not alone! We all are parts of opensource community, everything we do is transparent. Every patch, every source of binary package is of course available freely. In Fedora's case at https://src.fedoraproject.org/.

If you encounter problem building software in new stack, your first instinct should be to check Fedora, Debian and other distros sources. There's a great chance you will find a fix for your issue there. (In case of Fedora we generally require "upstream-first", there's even bigger chance the fix was already submitted upstream).

GNU C Library 2.31 released

Posted Feb 5, 2020 11:53 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> Can I point out that I never said "insider"? If you want to insist that quotation marks are to be used only to precisely quote someone, you might want to try and do that.

Let's replace "insider" with the virtually identical "someone on the inside", sure

" OP said that Fedora had already taken care of it; if they've already checked all their packages for the problem, it's probably because they have a developer working on glibc who was testing early releases and knew that this change was happening. There's certainly a difference between Fedora and most distributions in the amount of manpower available."

OP talked about Fedora packagers. There is nothing special done by Fedora Glibc maintainers. The long tail of Fedora packages maintained by volunteers is not all that different in manpower from other distributions btw

> Users, in a free software world, write their own code and sometimes even create their own distributions.

Some will play the role of developers and distribution integrators but then they will have to do the work associated with it. Whenever there is a major version of GCC or Glibc, changes are routinely done by upstream projects to cope up with it. Given that this is free software, patches are routinely reused from one distribution to another or from upstream to distributions and/or vice versa. This isn't anything new here

GNU C Library 2.31 released

Posted Feb 5, 2020 4:22 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (5 responses)

Since you chose to use the term "free software," I will assume that you intend to refer to this definition specifically. While there certainly are other definitions floating around, I tend to believe that you would've clarified if you meant something else (especially after others accused you of being unclear).

According to that definition:

A program is free software if the program's users have the four essential freedoms: [footnote omitted]

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help others (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Could you please clarify which of those four freedoms you believe are violated here, and in what manner?

GNU C Library 2.31 released

Posted Feb 5, 2020 5:58 UTC (Wed) by dvdeug (subscriber, #10998) [Link] (4 responses)

Freedom 1. When you say a change in libc is only of concern to distributors, you're saying most users don't need to be able to study or change the code for the programs they use.

GNU C Library 2.31 released

Posted Feb 8, 2020 20:37 UTC (Sat) by nix (subscriber, #2304) [Link] (3 responses)

That wasn't what was meant. What was meant is that Fedora routinely throws bleeding-edge glibcs at Rawhide and most especially deprecations are tested across the whole of Fedora (and also the whole of Debian). There's nothing special or privileged about this: if you are concerned about some software of yours, you can follow the glibc list and test that, too, whenever you see fit, and say "hey, your change to deprecate <sys/frobozz.h> breaks all versions of the FooBar software ever released". Existing software using interfaces *is* actually considered as an argument not to rapidly remove them :) this does not only apply to distro software.

GNU C Library 2.31 released

Posted Feb 10, 2020 7:46 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (2 responses)

When someone says "Don't worry, it is already sorted out by distributions", that is saying something is special and privileged about distributions.

Let's talk about realistic things; how often is glibc tested with bleeding-edge versions of make, or GCC, or coreutils? I've compiled my own kernel and my own GCC, but never dared compile my own glibc; the kernel is set up so I can switch back and forth between versions, and GCC won't hard-break my system. This may be unfair, but I feel like my system is going to break, and I'm going to get told "if you had just read the entire installation guide, you would have known you needed to add --with-sse unless you wanted x87 used by default / --with-sse is outdated and can't be used without breaking compatibility." This thread certainly hasn't made me trust the glibc manual more.

It's reasonable to say that distributions should be testing bleeding-edge glibcs, even if that takes more time than a small distribution may have. I think it's unreasonable to ask application developers to do so, which is why things are deprecated, so developers testing on a bleeding-edge distro get a glibc release cycle of warning.

GNU C Library 2.31 released

Posted Feb 10, 2020 15:12 UTC (Mon) by nix (subscriber, #2304) [Link]

Well, I test it with bleeding-edge GCC fairly often (and have multiple systems with hand-installed glibc -- the installation is a bit fiddly because there is one symlink you must *always* have pointing at the right ELF interpreter, and the whole of the rest of glibc's shared libraries must be installed before you do that or every dynamically linked program you run will probably dump core). But that's not actually that hard to get right (and sane people, i.e. not me, would build a glibc package from upstream sources and then install that, avoiding all that trouble).

You can mostly tell if glibc works before you install it, with a make check (and it's a *really* bad idea to install it *without* doing a make check and making sure that there aren't too many fails and that any fails that do appear don't seem to be too serious: 1 ulps math errors are fine, coredumps running every generated binary are probably not).

I'd agree that deprecation cycles are a good idea -- but if it turns out after release that making a symbol a compat symbol was a bad idea and it's breaking more than expected, it's perfectly doable to un-compat it and make it public again for the next release (and it would probably be considered acceptable to make it public in the stable release branch, too, as an ABI-unbreak). I cannot recall this *ever* happening for a major architecture, which says something about how cautious glibc's deprecation process really is.

GNU C Library 2.31 released

Posted Feb 13, 2020 17:24 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> When someone says "Don't worry, it is already sorted out by distributions", that is saying something is special and privileged about distributions.

Well yes, they have huge archives of software and huge build farms where they can arrange to build every single package from source and file bugs for any resulting failures.

See for example the Debian GCC7 transition (https://wiki.debian.org/GCC7) which generated over 450 bugs in various packages across the archive. Maintainers pick these up and forward them to upstream so that by the time you get around to installing GCC7 all the upstream packages you care about have already been fixed. This is a tremendous public service that benefits us all (not in the least by finding compiler bugs before most people run into them).

So yes, they are privileged and special, but not in any way that anyone else with the resources couldn't be. In fact, with the cloud these days an individual with a credit card could probably do the same. They'd probably get bored after the 50th bug though.

GNU C Library 2.31 released

Posted Feb 3, 2020 20:30 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (12 responses)

> It wasn't removed, it's just not available to newly linked binaries. Existing binaries will still work.

It's not GNU C, it's the GNU C library. The compiler and library are worked on by a different set of people, who coordinate about as closely and as well as the kernel developers with either of them. It's a little bit of pedantry, but I think it's important to remember.

Less pedantically, this is a GNU project, by the Free Software Foundation. One of the founding issues of the FSF was having printer drivers they couldn't fix because they couldn't get the source, and their whole mission is everyone having the source and right to change it. Separately from the deprecation issue, willfully breaking source code and doing extra work to leave the binaries working seems counter to their mission. Dropping it from the library or making the compiler issue loud deprecation warnings when compiling are both better than making something binary-only.

GNU C Library 2.31 released

Posted Feb 3, 2020 20:31 UTC (Mon) by dvdeug (subscriber, #10998) [Link]

Sorry, that first part about GNU C versus the GNU C library should have been a response to BirAdam.

GNU C Library 2.31 released

Posted Feb 4, 2020 1:06 UTC (Tue) by Wol (subscriber, #4433) [Link] (7 responses)

> Dropping it from the library or making the compiler issue loud deprecation warnings when compiling are both better than making something binary-only.

And dropping it from the library will break a bunch of programs that don't have source ... which won't please users when all their old commercial stuff stops working ...

Cheers,
Wol

GNU C Library 2.31 released

Posted Feb 4, 2020 2:45 UTC (Tue) by dvdeug (subscriber, #10998) [Link] (3 responses)

I expect RMS has the world's smallest violin for that occasion. I mean, I literally wouldn't be surprised if he pulled one out.

In general, that's one of the ways source disappears. It stops compiling, and instead of sending someone to delve into ancient code to fix it, you keep the binary, editing the binary directly if necessary.

In this specific case, no old commercial stuff should be calling this function. I use more proprietary code than RMS, but proprietary Linux system code is a bad idea and unnecessary. And any code that does use this is not year-2038 safe and must be recompiled or dumped before Y2.38K comes around. Encouraging people to keep it as binary instead of putting work into fixing the code or replacing the program is the worst thing you can do in this case.

GNU C Library 2.31 released

Posted Feb 4, 2020 10:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] (2 responses)

> I expect RMS has the world's smallest violin for that occasion. I mean, I literally wouldn't be surprised if he pulled one out.
Who cares about about RMS?

> In general, that's one of the ways source disappears. It stops compiling, and instead of sending someone to delve into ancient code to fix it, you keep the binary, editing the binary directly if necessary.
Hogwash, you just install an old version of the glibc headers or fix the program. Nobody in their right mind will edit a binary when the source code has not actually been lost.

> I use more proprietary code than RMS, but proprietary Linux system code is a bad idea and unnecessary.
If it's a bad idea and unnecessary then why are you using it? That doesn't even pass the laugh test.

> Y2.38K comes around. Encouraging people to keep it as binary instead of putting work into fixing the code or replacing the program is the worst thing you can do in this case.
What a load of bullshit. Removing this function from the glibc headers encourages maintainers to fix their program, and it avoids irritating users who are usually not in a position to do so. It's clearly the best of both worlds.

GNU C Library 2.31 released

Posted Feb 4, 2020 21:43 UTC (Tue) by coriordan (guest, #7544) [Link]

> Who cares about about RMS?

A very large number of people. It's because of the multiple absolutely huge things he's done since 1983. I won't list them, it's impossible that you don't know.

GNU C Library 2.31 released

Posted Feb 5, 2020 0:01 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

> Who cares about about RMS?

The GNU C library _is_ a GNU project. RMS could be taken as metonymy for the whole FSF there, if it helps.

> Hogwash, you just install an old version of the glibc headers

Would that work? I'd think you'd actually have to install a whole old glibc in a container or virtual machine to build it. I'm absolutely sure that's not documented as working.

> Nobody in their right mind will edit a binary when the source code has not actually been lost.

It's usually a multiple step process. Someone goes to make a change, and backs away in horror, and decides it's good enough as it is. By the time someone else edits the binary, they're looking at code that emits literally hundreds of errors and more warnings when you try to compile it, maybe a note that "you should not use EGCS to compile this; stick with GCC 2.5.2 or earlier" from the last compilation. Maybe it was never fully updated to C89, and the last change was to remove gets in a quick and dirty way. What's safer and quicker, carefully changing a few bytes in a binary and single-stepping it in a debugger, or fixing thousands of lines of code and hoping it doesn't have aliasing issues or other silent problems, knowing that any problems, including the new compiler not miscompiling it like the old compiler did, or it running too fast, are likely to be dropped at their doorstep? (Code like this never has test suites.) And once a program has been binary patched once, it's very hard to go back to the original source.

I'd bet a lot of the code being binary-patched in institutions is not because the original code has been lost. It's because it worked, and the risks of bringing it forward and compiling it on a new compiler for a new standard version was deemed higher than cautiously patching working binary as little as possible.

> > I use more proprietary code than RMS, but proprietary Linux system code is a bad idea and unnecessary.
> If it's a bad idea and unnecessary then why are you using it? That doesn't even pass the laugh test.

And you didn't think enough of me to reread what I wrote. I have a fully stocked Steam library; I don't have proprietary Linux system code.

> Removing this function from the glibc headers encourages maintainers to fix their program, and it avoids irritating users who are usually not in a position to do so.

Again, this division. What active maintainers are using stime? I'm going off the assumption that this was in fact practically eclipsed by settimeofday, that in actively maintained distributions the few programs that set time don't use stime to do so. If someone has stuck on a 1995 release of a package, they're both the user and the maintainer. At best, the sysadmin is both the person upgrading glibc and the maintainer who has to fix programs idiosyncratic to that system that still use stime.

GNU C Library 2.31 released

Posted Feb 4, 2020 12:53 UTC (Tue) by andyc (subscriber, #1130) [Link] (2 responses)

> And dropping it from the library will break a bunch of programs that don't have source ... which won't please users when all their old commercial stuff stops working ...

That should be fairly easily worked around with LD_PRELOAD...

GNU C Library 2.31 released

Posted Feb 4, 2020 14:00 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

How is that better than just not breaking users' programs in the first place?

GNU C Library 2.31 released

Posted Feb 4, 2020 16:55 UTC (Tue) by andyc (subscriber, #1130) [Link]

> How is that better than just not breaking users' programs in the first place?

I didn't say it was better. But at least you're not totally fscked.

Anyway, if you're reliant on some old binary only thing, you've probably got more serious problems...

GNU C Library 2.31 released

Posted Feb 4, 2020 15:50 UTC (Tue) by zwol (guest, #126152) [Link] (2 responses)

> Dropping it from the library or making the compiler issue loud deprecation warnings when compiling are both better than making something binary-only.

We *never* drop anything completely from the library. Making symbols unavailable to newly linked binaries is the most aggressive form of removal we ever use. This is not because we care more about old proprietary binaries than free software; it's because we don't want to make people recompile their entire operating system every time they update the C library. Imagine if you updated to glibc 2.31 and that suddenly made your NTP daemon refuse to start until you could get around to rebuilding it. Sysadmins would hate that.

(footnote: there's been talk about completely removing some really old symbols, associated with features that we have reason to believe were *never used*, like the 1995-era attempt to make stdio FILE and iostream filebuf be the same object, but so far that hasn't actually happened.)

GNU C Library 2.31 released

Posted Feb 4, 2020 22:48 UTC (Tue) by dvdeug (subscriber, #10998) [Link]

That's a good point in general.

However, imagine if you updated to glibc 2.31 and found out you should probably recompile your NTP daemon to get 64 bit time, or maybe change a hardcoded string. But there's a function it uses that somehow the old binary can use and a straight recompilation of the old code can't find. I can't imagine sysadmins being thrilled about that, either.

I object to going to the most aggressive form of removal without warning, but I do at least why you do this now.

GNU C Library 2.31 released

Posted Feb 5, 2020 21:52 UTC (Wed) by arekm (guest, #4846) [Link]

These days even recompiling is not enough. Thanks to seccomp, new syscalls etc. glibc 2.31 needs openssh to be patched to allow clock_gettime64 systall etc.

GNU C Library 2.31 released

Posted Feb 4, 2020 15:42 UTC (Tue) by zwol (guest, #126152) [Link] (1 responses)

> Look at the man page. There's no mention of [stime] being deprecated, or even that there's better choices

Yes, both the Linux manpages and the official glibc manual could have done a better job of communicating that this function is obsolete. Our error was to assume everyone already knew that, because it's so obsolete that its specification is absent from the *1997* edition of the Single Unix Specification. (Type "stime" into the search box at https://pubs.opengroup.org/onlinepubs/7990989775/ and you'll see that nothing comes up. I think it *was* mentioned in the 1995 edition, but I'm not having any luck finding an online copy of that, so I'm not sure.)

Compare the situation with gettimeofday, where POSIX.1-2001 [https://pubs.opengroup.org/onlinepubs/009695399/functions...] simply describes the function, and POSIX.1-2008 [https://pubs.opengroup.org/onlinepubs/9699919799/function...] says "obsolescent, may be removed in a future edition", and the Linux manpage for gettimeofday *does* reflect that.

The official glibc manual *has* been updated to reflect that stime is obsolescent. Speaking only for myself, I assume everyone's reading the latest edition of the manual on the web at https://www.gnu.org/software/libc/manual/html_node/ anyway, so it didn't occur to me to suggest that those changes be backported to older release branches. I don't know anything about the process for updating the Linux manpages, but I know that Michael Kerrick has been involved in the discussion of the Y2038 work (which this was part of) so I assume he will get to an update eventually.

In general, please be aware that if the glibc project doesn't do something you think it should have, that's almost certainly because nobody could carve out free time to do it. Despite being "such a core library", most of its maintainers are *not* paid to do general maintenance on it. At best, some of us are paid to make specific improvements that our employers want. In particular, the official manual has been in dire need of a complete revision since, um, probably about 2001, but it'd be six months of full-time work for a skilled tech writer, and nobody's volunteering or funding that time. I have heard tales that the FSF *used* to fund that sort of thing, but they haven't in *my* memory, which goes back to about 2001.

GNU C Library 2.31 released

Posted Feb 4, 2020 22:19 UTC (Tue) by dvdeug (subscriber, #10998) [Link]

> Our error was to assume everyone already knew that, because it's so obsolete that its specification is absent from the *1997* edition of the Single Unix Specification.

Do you know that it was in any edition of the Single Unix Specification? We have programmers who weren't alive in 1997 doing real work today; I don't know why you would expect them to know that the SUS is relevant here. The glibc manual can be read as saying that's okay to use if you don't need better than second resolution. I'm glad that the POSIX standard is online, but it's common enough for ANSI/ISO/IEEE standards to not be available online that I wouldn't have guessed it. Like always, the manpages and manuals are the source of most programmers, not the standards.

These standards are largely moot; all the world is a VAX^h^h^h^h^h Linux. For Unix-like systems, there's GNU/Linux and Linux on Windows 10 and Mac OS X, and the BSDs if one is feeling friendly to our open source cousins. For stime, I doubt you can set time on Windows from Linux, and I wouldn't feel right trying on Mac OS X; it wouldn't be helpful to users of that system. Even more generally, I care about two systems and if there's Mac OS X demand, there will be non-Linux-box Windows demand, making it three, and one of those non-POSIX.

> Speaking only for myself, I assume everyone's reading the latest edition of the manual on the web at https://www.gnu.org/software/libc/manual/html_node/ anyway,

The fact that the manual released with a version mentions that a feature is not supported is not a response to someone upset that there was no warning that the feature wasn't going to get supported.

> In general, please be aware that if the glibc project doesn't do something you think it should have, that's almost certainly because nobody could carve out free time to do it.

I'm sorry about that, but it's not really relevant. Deprecating something this release and deleting it next, instead of removing it directly, isn't exactly something that takes a lot of time; it may in fact buy you an extra release cycle to get things done.

GNU C Library 2.31 released

Posted Feb 3, 2020 12:52 UTC (Mon) by azz (subscriber, #371) [Link]

For anyone building an experimental system with glibc 2.31, in addition to the GCC/LLVM ASan patch mentioned in the release notes, it might be useful to know that the current OpenSSH (8.1p1) needs some patches backported to update the system call filter - grab the last few from here. Without those, it'll just close the connection when you try to log in, as nanosleep causes a SIGSYS. Otherwise it all seems to work well so far!

GNU C Library 2.31 released

Posted Feb 6, 2020 14:18 UTC (Thu) by jmclnx (guest, #72456) [Link]

Some day ftime() will be replaced for GNU/Linux. Eventually getting system date/time will be a bit more complex.

Right now, for date/time, I need to #define the BSDs, but AIX and Linux worked the same. So at some point I guess we will need to start wrapping date/time functions for glib (Linux) with #defines. Keeps me employed I guess :)

Reading the above, to me, it seems these changes relate to 2038 ? If so Open/Net BSD transitioned in a manner that at worse required a re-compile for 32 bit objects, but no code changes. I wonder if these changes are trying to avoid a recompile for 32 bit ?


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds