Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration

[Stafford Horne via Libc-alpha <libc-alpha@sourceware.org>]

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