Message ID | 55D1FDAE.6000000@panix.com |
---|---|
State | New |
Headers | show |
On 08/17/2015 05:28 PM, Zack Weinberg wrote: > On Mon, Aug 17, 2015 at 11:08 AM, Zack Weinberg <zackw@panix.com> wrote: >> Just now I did this again and also ran `git clean -dxf` in the source >> tree (which deleted only editor backups) and -- this is a little weird >> -- it compiles without complaint, but the VERSION_libc_GLIBC_2_xx >> #defines in abi-versions.h only go up to 2_22. > > I take that back. I *am* getting the same warning as Stefan, it just > didn't cause a build failure and scrolled off the top of my terminal. > The misc/Versions change suggested by Mike does cure the problem, so > here is a properly formatted patch. > > zw > For information: the testet architectures were s390x and x86_64. VERSION_libc_GLIBC_2_23 is defined with this patch and the warning does not occur anymore. Verified on both architectures. Bye Stefan
On 17 Aug 2015 11:28, Zack Weinberg wrote: > On Mon, Aug 17, 2015 at 11:08 AM, Zack Weinberg <zackw@panix.com> wrote: > > Just now I did this again and also ran `git clean -dxf` in the source > > tree (which deleted only editor backups) and -- this is a little weird > > -- it compiles without complaint, but the VERSION_libc_GLIBC_2_xx > > #defines in abi-versions.h only go up to 2_22. > > I take that back. I *am* getting the same warning as Stefan, it just > didn't cause a build failure and scrolled off the top of my terminal. > The misc/Versions change suggested by Mike does cure the problem, so > here is a properly formatted patch. thanks, merged now -mike
On 08/18/2015 09:29 AM, Mike Frysinger wrote: > On 17 Aug 2015 11:28, Zack Weinberg wrote: >> On Mon, Aug 17, 2015 at 11:08 AM, Zack Weinberg <zackw@panix.com> wrote: >>> Just now I did this again and also ran `git clean -dxf` in the source >>> tree (which deleted only editor backups) and -- this is a little weird >>> -- it compiles without complaint, but the VERSION_libc_GLIBC_2_xx >>> #defines in abi-versions.h only go up to 2_22. >> >> I take that back. I *am* getting the same warning as Stefan, it just >> didn't cause a build failure and scrolled off the top of my terminal. >> The misc/Versions change suggested by Mike does cure the problem, so >> here is a properly formatted patch. > > thanks, merged now > -mike Mike, Zack, Could one of you please update "Packaging Changes" for 2.23 to indicate exactly what happens if you use the header and how distributions should change their packages? The more detail the better, but if all we can say is "You need to from this API to that API," that's fine also. Some record of this requirement is important. https://sourceware.org/glibc/wiki/Release/2.23#Packaging_Changes Cheers, Carlos.
On Tue, Aug 18, 2015 at 10:51 AM, Carlos O'Donell <carlos@redhat.com> wrote: > > Could one of you please update "Packaging Changes" for 2.23 to indicate > exactly what happens if you use the header and how distributions should > change their packages? The more detail the better, but if all we can say > is "You need to from this API to that API," that's fine also. Some record > of this requirement is important. Here's suggested text. If you grant wiki account 'ZackWeinberg' permission to edit, I can take care of formatting and stuff. zw * The header file `regexp.h` (not to be confused with `regex.h`) is no longer supported. (This header was formerly part of SUS, but was deprecated in 1994 and removed from the standard in 2001; moreover, the glibc implementation suffered from memory leaks which were impractical to fix. See https://sourceware.org/bugzilla/show_bug.cgi?id=18681 for more information.) Binary backward compatibility is preserved, and glibc still installs a header file with this name, but it contains only an `#error` directive. Therefore, no packaging changes are required, but application developers and distribution maintainers should be aware that formerly-working programs may fail to compile as a result of this change. Such programs should be updated to use `regex.h` instead. `regcomp` is the replacement for the `compile` function and its associated macros, and `regexec` is the replacement for the `step` and `advance` functions and their associated global variables. [link each function name to its documentation]
On 08/18/2015 12:37 PM, Zack Weinberg wrote: > On Tue, Aug 18, 2015 at 10:51 AM, Carlos O'Donell <carlos@redhat.com> wrote: >> >> Could one of you please update "Packaging Changes" for 2.23 to indicate >> exactly what happens if you use the header and how distributions should >> change their packages? The more detail the better, but if all we can say >> is "You need to from this API to that API," that's fine also. Some record >> of this requirement is important. > > Here's suggested text. If you grant wiki account 'ZackWeinberg' > permission to edit, I can take care of formatting and stuff. Done. You're in the EditorGroup now. > zw > > * The header file `regexp.h` (not to be confused with `regex.h`) is > no longer supported. (This header was formerly part of SUS, but was > deprecated in 1994 and removed from the standard in 2001; moreover, > the glibc implementation suffered from memory leaks which were > impractical to fix. See > https://sourceware.org/bugzilla/show_bug.cgi?id=18681 for more > information.) > > Binary backward compatibility is preserved, and glibc still > installs a header file with this name, but it contains only an > `#error` directive. Therefore, no packaging changes are required, but > application developers and distribution maintainers should be aware > that formerly-working programs may fail to compile as a result of this > change. Such programs should be updated to use `regex.h` instead. > `regcomp` is the replacement for the `compile` function and its > associated macros, and `regexec` is the replacement for the `step` and > `advance` functions and their associated global variables. [link each > function name to its documentation] > Looks good to me. I know we have distro people watching our release pages and they look for guidance from us here, so I'll point any package fails in Fedora to this note. c.
OK, I have added the text with some slight revisions. I could not figure out how to put monospace text inside a hyperlink so the formatting is slightly inconsistent.
On 08/18/2015 03:20 PM, Zack Weinberg wrote: > OK, I have added the text with some slight revisions. I could not > figure out how to put monospace text inside a hyperlink so the > formatting is slightly inconsistent. I have never tried hard to make it work. I would be tempted to do: `regcomp`[''''''[[https://www.gnu.org/software/libc/manual/html_node/POSIX-Regexp-Compilation.html|1]]''''''] ... [1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Regexp-Compilation.html Note: The use of '''''' (SixQuotes) causes the parser to reset and allow you to surround a square bracket quote with more square brackets. c.
* misc/Versions: Add empty GLIBC_2.23 stanza, to prevent undefined macro warnings in regexp.c. --- misc/Versions | 3 +++ 1 file changed, 3 insertions(+) diff --git a/misc/Versions b/misc/Versions index 534d1a3..671f487 100644 --- a/misc/Versions +++ b/misc/Versions @@ -149,6 +149,9 @@ libc { GLIBC_2.16 { __getauxval; getauxval; } + GLIBC_2.23 { + # SHLIB_COMPAT(GLIBC_2_0, GLIBC_2_23) used in regexp.c + } GLIBC_PRIVATE { __madvise; __mktemp; -- 2.5.0