glibc>=2.34 (RHEL 9) integration of libpthread, libdl, libutil, libanl into libc

[mbargull]

Comment:

In today's conda-forge/core meeting the question came up whether we'd need any changes regarding libpthreads' (et al.) integration into libc itself for glibc>=2.34 (used in RHEL 9 onward).

In contrast to libcrypt.so.1's removal (in RHEL 9 onward and generally in future glibc>=3.29 releases) for which we do have to make changes (see gh-52), we probably don't here since backwards compatibility is given.
See upstream changelog:
https://sourceware.org/git/?p=glibc.git;a=blame;f=NEWS;hb=refs/tags/glibc-2.34#l12 :

• In order to support smoother in-place-upgrades and to simplify
  the implementation of the runtime all functionality formerly
  implemented in the libraries libpthread, libdl, libutil, libanl has
  been integrated into libc. New applications do not need to link with
  -lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility,
  empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are
  provided, so that the linker options keep working. Applications which
  have been linked against glibc 2.33 or earlier continue to load the
  corresponding shared objects (which are now empty). The integration
  of those libraries into libc means that additional symbols become
  available by default. This can cause applications that contain weak
  references to take unexpected code paths that would only have been
  used in previous glibc versions when e.g. preloading libpthread.so.0,
  potentially exposing application bugs.

Opening this issue here so we are at least aware of the changes and can track potential adjustments.

@chenghlee, if you have encountered cases for which this change causes issues, do let us know!