NEWS: Mention libpthread, libdl, libutil, libanl integration

Message ID 871r7roomm.fsf@oldenburg.str.redhat.com
State New
Headers show
Series
  • NEWS: Mention libpthread, libdl, libutil, libanl integration
Related show

Commit Message

Florian Weimer via Libc-alpha July 21, 2021, 12:08 p.m.
---
 NEWS | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

Comments

Florian Weimer via Libc-alpha July 29, 2021, 2:19 a.m. | #1
On 7/21/21 8:08 AM, Florian Weimer via Libc-alpha wrote:
> ---

>  NEWS | 14 ++++++++++++++

>  1 file changed, 14 insertions(+)

> 

> diff --git a/NEWS b/NEWS

> index efc105b6b4..dd333109a5 100644

> --- a/NEWS

> +++ b/NEWS

> @@ -9,6 +9,20 @@ Version 2.34

>  

>  Major new features:

>  

> +* All functionality formerly implemented in the libraries libpthread,

> +  libdl, libutil, libanl has been integrated into libc.  New

> +  applications do not 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.


A user reading this may wonder why we did this. There are some other NEWS
entries that need similar treatment. We should be explicit in spelling
out the reason: "improved in-place-upgrades" and result: "all libraries
merged into libc."

Suggest:

* 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. ...

Looking forward to a v2.

> +

>  * When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,

>    PTHREAD_STACK_MIN is no longer constant and is redefined to

>    sysconf(_SC_THREAD_STACK_MIN).

> 



-- 
Cheers,
Carlos.
Florian Weimer via Libc-alpha July 29, 2021, 7:56 a.m. | #2
On Wed, 21 Jul 2021, Florian Weimer via Libc-alpha wrote:

> --- a/NEWS

> +++ b/NEWS

> @@ -9,6 +9,20 @@ Version 2.34

>  

>  Major new features:

>  

> +* All functionality formerly implemented in the libraries libpthread,

> +  libdl, libutil, libanl has been integrated into libc.  New

> +  applications do not link with -lpthread, -ldl, -lutil, -lanl anymore.


"do not need to link"? (missing "need")

This is also true for relinking old applications. Maybe rephrase to avoid
making the unintended implication? (or simply drop "new")

Alexander

Patch

diff --git a/NEWS b/NEWS
index efc105b6b4..dd333109a5 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,20 @@  Version 2.34
 
 Major new features:
 
+* All functionality formerly implemented in the libraries libpthread,
+  libdl, libutil, libanl has been integrated into libc.  New
+  applications do not 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.
+
 * When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
   PTHREAD_STACK_MIN is no longer constant and is redefined to
   sysconf(_SC_THREAD_STACK_MIN).