bug#53005: [PATCH 1/1] gnu: glibc: Preserve "__pthread_key_create" symbol.

[Simon South]

Leo Famulari <leo@famulari.name> writes:
> First, how was the LUKS2 volume created? Was it created by Guix
> System?

No, this would've been a volume I created myself; I expect only users
who are partitioning their drives manually or replacing an existing
system would encounter this.  The Guix manual actually instructs users
to select a different PBKDF algorithm[0] for compatibility with GRUB,
one that by coincidence does not appear to be affected[1].

However, remember this problem potentially affects _all_ packages that
use threads in C or C++.  It appears that dynamically-linked executables
(i.e. the vast majority) generally sidestep the problem by avoiding any
"dangerous" methods in libgcc, but there could still be crashing bugs
elsewhere waiting to be discovered.

> Is Guix doing something wrong that requires the workaround?

This is all a consequence of stripping libraries with the
"--strip-unneeded" option instead of "--strip-debug"[2], in the interest
of reducing store sizes.  The man page for "strip" describes it like
this:

  --strip-unneeded
      Remove all symbols that are not needed for relocation processing.

My personal opinion is that this option makes sense for executables but
is too aggressive to use on libraries.

  - Unlike executables, we generally want to do more with a library than
    just relocate it.

  - Providing a rich set of symbols is normally a desirable feature of a
    library and not a bug.

  - Only at link time is it possible to say which of a library's symbols
    are truly relevant; therefore, the selection of symbols to retain
    should logically be performed by the linker, not an automated step
    during the library's packaging (outside of any link context).

    Specifically, it's impossible for us to predict cases like this one,
    where a symbol not obviously needed to use a library is nonetheless
    relied on by an application.

However, Guix's gnu-build-system provides only a single "#:strip-flags"
argument that is applied to all of a package's binaries.  So, as an
alternative solution, we could either extend that mechanism to allow
different sets of flags to be applied to different types of binaries, or
revert the changes (commits f32a6055a5 and e0f31baacc) altogether.  I
didn't expect either of those options would be popular, and truthfully,
everything does appear to work okay (for now) with only this one change
to glibc.

[0] 
https://guix.gnu.org/en/manual/devel/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html#Disk-Partitioning
[1] But then, neither GRUB nor the Guix installer are commonly used on
    non-Intel systems.
[2] Originally proposed in https://issues.guix.gnu.org/42555

-- 
Simon South
simon@simonsouth.net