Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On Wed, Apr 19, 2023, at 5:23 PM, Paul Eggert wrote: > On 2023-04-11 17:10, Zack Weinberg wrote: >> I'm also happy with this resolution. I do not have time to do the Autoconf >> work until the weekend. > > I notice you were careful to not say *which* weekend. :-

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On Mon, Apr 10, 2023, at 7:00 PM, Paul Eggert wrote: > On 2023-04-10 15:36, Bruno Haible wrote: >> I like this. Thanks. > > OK, then let's hear Zack's opinion and hopefully move forward. I'm also happy with this resolution. I do not have time to do the Autoconf work until the weekend. zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On Mon, Apr 10, 2023, at 10:12 AM, Pádraig Brady wrote: > On 10/04/2023 14:40, Bruno Haible wrote: >> Hi Paul, In yesterday's changes, you added to the Gnulib >> documentation, section "Avoiding the year 2038 problem", wording that >> >>* explicitly recommends the ‘year2038-required’ module, wh

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote: ... > If Clang's threatened pickiness were of some real use elsewhere, it > might be justifiable for default Clang to break Autoconf. But so far we > haven't seen real-world uses that would justify this pickiness for > Autoconf's use of 'char

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote: >> On 13 Nov 2022, at 00:43, Paul Eggert wrote: >> >> Although there will be problems with people who run "./configure >> CFLAGS='-Werror'", that sort of usage has always been problematic and >> unsupported by Autoconf, so we can simply contin

Re: How can Autoconf help with the transition to stricter compilation defaults?

Demi Marie Obenour writes: > On 11/10/22 15:19, Paul Eggert wrote: >> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf >> supported K&R C, C89, C99, etc. At some point (I'm not sure when), >> Autoconf started requiring C89 or later. Is it now OK for Autoconf to >> requi

Re: On time64 and Large File Support

Sam James writes: >> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha >> wrote: >> I am honestly not sure what to do about this in the long term, but for >> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it >> makes sense to back

Re: On time64 and Large File Support

Sam James writes: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> We need to support legacy binaries on i386. Few libraries are >> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >> to LFS or time64 needs to be evaluated on a per-library basis. For most >> distribu

Re: bool and C23

Please note consolidated reply to both Paul and Bruno. On Sun, Aug 21, 2022, at 5:25 PM, Paul Eggert wrote: > On 8/21/22 07:59, Zack Weinberg wrote: >> Paul Eggert: >>> Zack Weinberg: >>>> @defmac AC_C_BOOL (@ovar{if-required}) >>> >>> How about if

Re: Request to revert the C version change

On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote: > I'm not happy about needing to kludge backward compatibility with the > older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it. As of commit 2d0f19d84ddb13412382674fd48e6fc5c2875d0e, Autoconf *trunk* should

Re: Request to revert the C version change

On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote: > I'm not happy about needing to kludge backward compatibility with the > older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it. It occurs to me that this would be less of a problem in the future if aclocal/autorec

Re: Request to revert the C version change

On Sun, Dec 20, 2020 at 11:54 AM Ross Burton wrote: > On Sun, 20 Dec 2020 at 16:46, Bruno Haible wrote: >> This patch is already in Gnulib since 2020-12-09. But when people >> run 'autoreconf' on an existing released tarball, they are effectively >> combining an older Gnulib with a newest Autocon

Re: Request to revert the C version change

On Sun, Dec 20, 2020 at 11:46 AM Bruno Haible wrote: > > Zack Weinberg wrote: > > $ diff -u m4/std-gnu11.m4{~,} > > --- m4/std-gnu11.m4~2020-08-30 11:27:01.0 -0400 > > +++ m4/std-gnu11.m42020-12-20 09:43:13.001477099 -0500 > > @@ -27,6 +27,8 @@ >

Re: Request to revert the C version change

On Wed, Dec 16, 2020 at 2:02 PM Zack Weinberg wrote: > On Wed, Dec 16, 2020 at 1:52 PM Ross Burton wrote: > > | checking for gcc option to enable C11 features... none needed > > | ../bison-3.7.4/configure: line 6187: syntax error near unexpected > > token `ac_cv_prog_cc_st

Re: Hidden files in autoconf 2.70 distribution?

On Wed, Dec 9, 2020 at 9:18 AM Bob Friesenhahn wrote: > On Tue, 8 Dec 2020, Zack Weinberg wrote: > > > > Yes, that’s intentional. Those files record information copied out of the > > git history. See build-aux/git-version-gen and maint.mk. > > I don't recall seeing

[PATCH] sc_error_message_uppercase: allow fully uppercased words

If an error message starts with an entire fully uppercased word, that’s probably a proper noun and it should stay that way. For instance, autoreconf has an error message that starts with "AM_GNU_GETTEXT is used, but ..."; AM_GNU_GETTEXT is the name of an Automake macro, it needs to stay uppercased

Re: AS_IF

On Mon, Oct 12, 2020 at 3:01 AM Paul Eggert wrote: > On 10/6/20 5:52 PM, Zack Weinberg wrote: > > I'm not sure we should say AS_IF/CASE > > are equivalent to plain shell if/case inside an AC_DEFUN; they do do > > more than just make the m4 expansion stack not be empty

Re: AS_IF

On Tue, Oct 6, 2020 at 5:57 PM Bruno Haible wrote: > Paul Eggert wrote in > : > > > AFAICS, this is relevant for code written directly into configure.ac. But > > > inside an AC_DEFUN it is irrelevant, because required macros are

Re: autoconf-2.69c released [beta]

On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible wrote: > > Paul Eggert wrote: > > > I don't know where you got this magic number 301-14265 from. > > > > I got it by checking out the then-current commit of Autoconf from Savannah > > git, > > and building from that. > > > > Presumably doing the right

Re: Results from running autoupdate on gnulib m4 files

On Sun, Sep 27, 2020 at 6:29 AM Gavin Smith wrote: > Because of the upcoming autoconf 2.70 release gives more warnings, I > checked the other files in gnulib in the m4 directory with > > autoupdate -v *.m4 2>&1 | tee log Thanks for doing this. I was getting set up to do it myself, but I got hung

Re: autoconf-2.69c released [beta]

On Sat, Sep 26, 2020 at 8:15 AM Gavin Smith wrote: > On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith wrote: > > > > > * Warnings about obsolete constructs are now on by default. > > > They can be turned off with '-Wno-obsolete'. > > > > > > > I have tried building the git development version of Tex

Re: 32bit or LTO movemail build fails on macOS

On Tue, Mar 24, 2020 at 10:58 PM Paul Eggert wrote: > > Thanks for the bug report. Does the attached patch to getopt-pfx-core.h fix > the > bug for you? > > I'll CC: this to bug-gnulib and to Zack Weinberg, who wrote that file. For > those > new to this thread, ple

Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

On Fri, Mar 13, 2020 at 10:49 PM Bruno Haible wrote: >> but when something goes > > wrong, the poor schmuck who has to debug it wants to know that it was > > the test for `ceil` (for instance) that hung the build, not the > > unrelated thing that happens to have been tested right before that. > >

Re: gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

On Fri, Mar 13, 2020 at 5:54 PM Bruno Haible wrote: > > [CCing autoc...@gnu.org] > > Hi Zack, > > > Abstractly, the best thing to do about this would be to remove the > > macro and change all of its uses to be AC_CACHE_CHECK, with proper > > messaging, instead. > > The point is that we don't want

gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

I'm doing groundwork for the long-overdue release of autoconf 2.70, and part of that is checking to make sure that various changes in development trunk since 2.69 haven't broken third-party macros. I noticed that gnulib-common.m4 contains a macro, gl_CACHE_VAL_SILENT, that attempts to make AC_CACH

Re: [PATCH 1/1] Y2038: add function __difftime64

On Thu, Jul 5, 2018 at 2:36 PM, Albert ARIBAUD wrote: > I have had a look at gnulib in the meantime, and I would like to know > if the following assumptions are correct: I can't comment on anything else at all, but: > - gnulib does not contain any module which provides the time_t type, but > s

Re: Sync gnulib regex with glibc

On Thu, Dec 21, 2017 at 11:50 AM, Adhemerval Zanella wrote: > The glibc testfile, bug-regex28.c, is related to BZ#3957 [1], which is not > strictly related to RE_SYNTAX_{E}GREP definition. On gnulib side the change > was done somewhat recently (2015) by 5a5a9388e. > > It does look like a correct c

Re: [PATCH 01/17] Regex: Fix spelling errors / typos.

On Tue, Dec 19, 2017 at 2:03 PM Paul Eggert wrote: > These typo changes are all in Gnulib, and would be fine to install in > glibc. > > Adding bug-gnulib to the CC list. For reference, the original email is > here: > https://sourceware.org/ml/libc-alpha/2017-12/msg00243.html I don’t think Arnol

Re: [PING] [PATCH 00/17] Regex: Make libc regex more usable outside GLIBC

On Tue, Dec 19, 2017 at 9:56 AM, Adhemerval Zanella wrote: > On 19/12/2017 15:43, Paul Eggert wrote: >> On 12/19/2017 04:52 AM, Adhemerval Zanella wrote: >>> Again, my understanding is we still aim to keep it in sync with gnulib, >>> so I think we should first integrate with current gnulib code on

Re: getopt copyright header

Sorry about that. glibc's default copyright headers refer to the library as a whole as being under the LGPL and it didn't occur to me to check whether the gnulib policy is different. On Fri, Oct 6, 2017 at 2:30 PM, Paul Eggert wrote: > Thanks, looks good to me.

Re: minus versus underscore in new getopt file names

On Sun, Apr 9, 2017 at 4:06 AM, Paul Eggert wrote: > Zack Weinberg wrote: >> I was being >> consistent with the existing getopt_int.h - maybe that should be >> renamed too? > > Maybe, but let's defer that as it's a separable change and it's to a > l

Re: GNU LIB build fails on macOS 10.12.4

> Please try the attached patch against Emacs master. > If it works I plan to install it into Emacs and propagate > it into Gnulib. This patch is incomplete. If gnulib cannot use __nonnull in getopt_{core,ext}.h, then there is no point trying to define it in getopt_cdefs.h. And you're going to n

Re: minus versus underscore in new getopt file names

On Sat, Apr 8, 2017 at 5:42 AM, Paul Eggert wrote: > Now that I think about it, the longstanding Gnulib and GNU tradition is to > use minus in file names rather than underscore. How about if we rename the > newly-introduced getopt source files to use minus instead of underscore? I don't think gli

Re: Merge getopt from gnulib to glibc and vice versa, eliminate __need_getopt

On Thu, Apr 6, 2017 at 6:48 PM, Paul Eggert wrote: > Thanks for doing this, as Gnulib and Glibc should be better-synchronized. In > the interests of helping this move along, I installed your proposed changes > into Gnulib, with the attached additional minor patches, the first of which > I hope you

Merge getopt from gnulib to glibc and vice versa, eliminate __need_getopt

The implementation of 'getopt' is shared between gnulib and glibc, but they have not been kept consistent in quite some time and there has been quite a bit of divergence. They also haven't really been *maintained* in either project. I set out simply to eliminate __need_getopt in both projects (se