From: Martin Sebor
* lib/mktime.c [DEBUG] (DEBUG): Rename to DEBUG_MKTIME. See:
https://sourceware.org/ml/libc-alpha/2016-01/msg00267.html
---
ChangeLog| 6 ++
lib/mktime.c | 12 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c9
On 01/12/2016 04:56 AM, Gavin Smith wrote:
The code for this output is in func_emit_autoconf_snippets; it
shouldn't be hard to swap them around. I can try to post a patch if
others agree this is the reason for the problem.
It might be simpler to change the modules/nl_langinfo file instead, by
In http://lists.gnu.org/archive/html/bug-autoconf/2015-12/msg0.html
Pavel Raiskup reports that ${1+"$@"} runs afoul of a bug in /bin/sh
(derived from ksh 93t+ 2010-03-05). ${1+"$@"} works around an ancient
bug long-dead shells, so remove the workaround.
* build-aux/announce-gen, build-aux/do-r
On 01/12/2016 06:38 AM, Gavin Smith wrote:
I recommend that NOTHING BE DONE about this failure.
Yes, Bruno's April 2011 review was pretty devastating. I don't think
it's even worth documenting PCC's bugs; there are too many, and useful
free compiliers like GCC are readily available.
* build-aux/announce-gen, build-aux/bootstrap:
* build-aux/do-release-commit-and-tag, build-aux/git-version-gen:
* build-aux/gitlog-to-changelog, build-aux/gnu-web-doc-update:
* build-aux/gnupload, build-aux/mkinstalldirs:
* build-aux/move-if-change, build-aux/prefix-gnulib-mk:
* build-aux/update-c
Using the "regex" module, I had the error
#error "Add case for new bitset_word_t size"
from regex_internal.h when using pcc under NetBSD.
$ pcc --version
pcc 1.2.0.DEVEL 20141228 for x86_64--netbsd
The problem appears to be that the C preprocessor thinks that
ULONG_MAX is a negative value. Wit
On 12 January 2016 at 12:28, Gavin Smith wrote:
> func_gl_gnulib_m4code_nl_langinfo ()
> {
> if ! $gl_gnulib_enabled_nl_langinfo; then
> gl_FUNC_NL_LANGINFO
> if test $HAVE_NL_LANGINFO = 0 || test $REPLACE_NL_LANGINFO = 1; then
> AC_LIBOBJ([nl_langinfo])
> fi
>
On 12 January 2016 at 00:53, Gavin Smith wrote:
> Maybe AC_REQUIRE isn't hoisting the code far enough? The code is
> remaining in the function corresponding to a gnulib module's code, and
> not going to the very top level. The code is expanded, but is executed
> too late.
So gnulib-m4.comp, which
