NEWS: Mention libpthread, libdl, libutil, libanl integration

  ---
 NEWS | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
  

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

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
  

On Wed, Jul 21, 2021 at 9:09 PM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> 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

Hello,

I have updated the OpenRISC port to GLIBC_2.35 as it is not upstream yet.
I noticed when building a few applications in buildroot (gdb,
sysvinit) that have
hard codings of -lutil, they now fail when compiling with the openrisc
toolchain.

I got them to compile by removing -luti.

How should we go about patching that in a way they can build with older versions
of glibc and with the openrisc toolchain on version 2.35.  Should they
detect the
glibc version?

Sysvinit issue:
  https://git.savannah.nongnu.org/cgit/sysvinit.git/tree/src/Makefile#n144

Buildroot GDB issue:
  https://github.com/buildroot/buildroot/blob/master/package/gdb/gdb-python-config#L32

-Stafford
  

* Stafford Horne via Libc-alpha:

> On Wed, Jul 21, 2021 at 9:09 PM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> 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
>
> Hello,
>
> I have updated the OpenRISC port to GLIBC_2.35 as it is not upstream yet.
> I noticed when building a few applications in buildroot (gdb,
> sysvinit) that have
> hard codings of -lutil, they now fail when compiling with the openrisc
> toolchain.
>
> I got them to compile by removing -luti.

I think we should change the makefiles so that we still keep building
libutil.a, but not the shared object, so that it's not necessary to
change build systems too much.  Similar for the other shared objects
that are now empty.  I'm open to other suggestions, though.
  

On Sat, Oct 09, 2021 at 02:18:09PM +0200, Florian Weimer wrote:
> * Stafford Horne via Libc-alpha:
> 
> > On Wed, Jul 21, 2021 at 9:09 PM Florian Weimer via Libc-alpha
> > <libc-alpha@sourceware.org> 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
> >
> > Hello,
> >
> > I have updated the OpenRISC port to GLIBC_2.35 as it is not upstream yet.
> > I noticed when building a few applications in buildroot (gdb,
> > sysvinit) that have
> > hard codings of -lutil, they now fail when compiling with the openrisc
> > toolchain.
> >
> > I got them to compile by removing -luti.
> 
> I think we should change the makefiles so that we still keep building
> libutil.a, but not the shared object, so that it's not necessary to
> change build systems too much.  Similar for the other shared objects
> that are now empty.  I'm open to other suggestions, though.

That seems to make sense, it would be nice if there was a way to have a
deprecated warning when an app tries to link in libutil etc.  This would
allow for project to clean up their makefiles to avoid unneeded linking.

I can't think of how that would be done though.

-Stafford
  

* Stafford Horne:

>> I think we should change the makefiles so that we still keep building
>> libutil.a, but not the shared object, so that it's not necessary to
>> change build systems too much.  Similar for the other shared objects
>> that are now empty.  I'm open to other suggestions, though.
>
> That seems to make sense, it would be nice if there was a way to have a
> deprecated warning when an app tries to link in libutil etc.  This would
> allow for project to clean up their makefiles to avoid unneeded linking.

We can eventually add such a warning, but I think it's premature.  The
empty .a file does not leave any trace at all at run time. And we have
to keep some of these libraries indefinitely anyway because POSIX
requires that certain -l options work.  Empty .a files are the easiest
way to achieve that.