* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-07-21 12:08 [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration Florian Weimer via Libc-alpha
@ 2021-07-29 2:19 ` Carlos O'Donell via Libc-alpha
2021-07-29 7:56 ` Alexander Monakov via Libc-alpha
2021-10-08 22:09 ` Stafford Horne via Libc-alpha
2 siblings, 0 replies; 7+ messages in thread
From: Carlos O'Donell via Libc-alpha @ 2021-07-29 2:19 UTC (permalink / raw)
To: Florian Weimer, libc-alpha
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-07-21 12:08 [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration Florian Weimer via Libc-alpha
2021-07-29 2:19 ` Carlos O'Donell via Libc-alpha
@ 2021-07-29 7:56 ` Alexander Monakov via Libc-alpha
2021-10-08 22:09 ` Stafford Horne via Libc-alpha
2 siblings, 0 replies; 7+ messages in thread
From: Alexander Monakov via Libc-alpha @ 2021-07-29 7:56 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-07-21 12:08 [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration Florian Weimer via Libc-alpha
2021-07-29 2:19 ` Carlos O'Donell via Libc-alpha
2021-07-29 7:56 ` Alexander Monakov via Libc-alpha
@ 2021-10-08 22:09 ` Stafford Horne via Libc-alpha
2021-10-09 12:18 ` Florian Weimer
2 siblings, 1 reply; 7+ messages in thread
From: Stafford Horne via Libc-alpha @ 2021-10-08 22:09 UTC (permalink / raw)
To: Florian Weimer; +Cc: GLIBC patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-10-08 22:09 ` Stafford Horne via Libc-alpha
@ 2021-10-09 12:18 ` Florian Weimer
2021-10-10 0:45 ` Stafford Horne via Libc-alpha
0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2021-10-09 12:18 UTC (permalink / raw)
To: Stafford Horne via Libc-alpha
* 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-10-09 12:18 ` Florian Weimer
@ 2021-10-10 0:45 ` Stafford Horne via Libc-alpha
2021-10-10 13:34 ` Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Stafford Horne via Libc-alpha @ 2021-10-10 0:45 UTC (permalink / raw)
To: Florian Weimer; +Cc: Stafford Horne via Libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration
2021-10-10 0:45 ` Stafford Horne via Libc-alpha
@ 2021-10-10 13:34 ` Florian Weimer
0 siblings, 0 replies; 7+ messages in thread
From: Florian Weimer @ 2021-10-10 13:34 UTC (permalink / raw)
To: Stafford Horne; +Cc: Stafford Horne via Libc-alpha
* 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.
^ permalink raw reply [flat|nested] 7+ messages in thread