Message ID | 871r7roomm.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | NEWS: Mention libpthread, libdl, libutil, libanl integration | expand |
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.
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).