Dear gnulib maintainers,
We recently updated gnulib to a newer revision in GNU Octave (currently
92d80242ad1344b5364ca9bd1d995d68c3a73ef7).
Since then we are seeing compilation errors like the following when targeting
Cygwin:
In file included from /usr/include/sys/reent.h:16,
Hi Bruno,
Bruno Haible wrote:
> Markus Mützel wrote:
> > However, it looks like $GNULIB_SRCDIR is empty for us. So, the change
> > doesn't seem to make a difference. Executing bootstrap after a revision
> > bump still fails if the bootstrap script was already run before.
>
> Oh, there were two
Hi Paul,
On 4/28/24 4:27 PM, Paul Eggert wrote:
> For test cases this is more a judgment call, but I prefer doing either
> the above or adjusting the warning flags, to ignoring warnings, as the
> other warnings can be useful at time.
Yeah, I could see these warnings making it hard to see ones tha
On 2024-04-28 04:03, Collin Funk wrote:
I will listen to the Makefile and*ignore* them now, or disable them
if they start annoying me. :)
Another possibility is to make each such variable 'static' if it's OK to
make it static, and to precede every other variable declaration like this:
int f
I've applied the attached patch updating the macro list in the
gnulib-cache.m4 documentation.
The macros seemed to match the order of the sed invocation in
func_import of gnulib-tool.sh, so most of it was just copying from
there and adjusting the gnulib-tool --help messages to fit the
existing doc
On 4/21/24 16:50, Bruno Haible wrote:
Good point. Yes, Python occasionally (rarely?) makes incompatible changes.
So, I've now created a continuous integration at [2]. If a Python release
is made that breaks gnulib-tool, this CI will notify me shortly afterwards,
and we will have time to adapt gnu
Hi Collin,
> I also noticed some macros were missing from the gnulib-cache.m4 list
> starting at line 375.
>
> Is it just out of date (git blame says ~2005)
Yes. I probably forgot that these macros were documented, when adding
extensions later.
> If it is the first case I can add them later
> t
Hi Bruno,
On 4/28/24 5:02 AM, Bruno Haible wrote:
>> +* doc/gnulib-tool.texi (Initial import): Update the example gnulib-tool
>> +invocation. Document the use of AC_CONFIG_MACRO_DIRS as an alternative
>> +to ACLOCAL_AMFLAGS.
> Thanks.
I also noticed some macros were missing from the g
> + * doc/gnulib-tool.texi (Initial import): Update the example gnulib-tool
> + invocation. Document the use of AC_CONFIG_MACRO_DIRS as an alternative
> + to ACLOCAL_AMFLAGS.
Thanks.
Document the following gnulib-tool change:
2021-12-19 Bruno Haible
gnulib-tool: Don't insist on ACLOCAL_AMFLAGS.
* doc/gnulib-tool.texi (Initial import): Update the example gnulib-tool
invocation. Document the use of AC_CONFIG_MACRO_DIRS as an alternative
to ACLOCAL_AMFLAGS.
---
ChangeLog
On 4/28/24 2:52 AM, Bruno Haible wrote:
> Thanks! OK to push in 1 or 2 days.
Sounds good.
>> Though, the correct way to fix this would be making instance variables
>> local when they are only used in one function.
>
> I agree that this kind of doing side effects on a GLConfig object that
> is al
Hi Bruno,
On 4/28/24 3:11 AM, Bruno Haible wrote:
>> Can I apply the attached patch which adds the 'static' specifier to
>> global variables in unit tests?
>
> No! While adding 'static' would be no harm in some tests (such as
> tests/jit/test-cache.c, tests/test-argp-version-etc.c, tests/test-arg
Hi Collin,
> Can I apply the attached patch which adds the 'static' specifier to
> global variables in unit tests?
No! While adding 'static' would be no harm in some tests (such as
tests/jit/test-cache.c, tests/test-argp-version-etc.c, tests/test-argp.c),
in other tests the purpose of the global
Hi Collin,
> > The 'libtests' value read from the config in self.emitter is
> > incorrect.
>
> This patch seems to support what I was saying here.
>
> diff --git a/pygnulib/GLTestDir.py b/pygnulib/GLTestDir.py
> index 002eb30267..11b067e085 100644
> --- a/pygnulib/GLTestDir.py
> +++ b/pygnulib/G
Markus Mützel wrote:
> However, it looks like $GNULIB_SRCDIR is empty for us. So, the change doesn't
> seem to make a difference. Executing bootstrap after a revision bump still
> fails if the bootstrap script was already run before.
Oh, there were two 'git checkout' commands and I enhanced only
Hi Bruno,
> > As a workaround we are applying the attached patch to the
> > bootstrap-funclib.sh script to automatically fetch from the remote gnulib
> > repository if the GNULIB_REVISION isn't found in the local gnulib Git
> > repository.
>
> Thanks for the patch. But note that GNULIB_REVISION
Collin Funk wrote:
> > If I understand correctly, sprintf should return 4 here correct? And
> > the buffer should have 5 NUL bytes. 4 from the arguments and 1
> > trailing, which is excluded from the return value.
Correct. I added a comment, because the situation in ISO C and POSIX has
changed, no
On 4/28/24 12:38 AM, Collin Funk wrote:
> If I understand correctly, sprintf should return 4 here correct? And
> the buffer should have 5 NUL bytes. 4 from the arguments and 1
> trailing, which is excluded from the return value.
I have no other systems to check this on, so I will trust my findings
Hi Bruno,
On 4/27/24 2:02 AM, Bruno Haible wrote:
> At this point of the investigations, it's too early for a patch.
> First, one needs to determine whether it's a bug in Gnulib or a
> bug in some package we rely on (typically gcc or glibc). In the
> latter case, we report the bug and wait for the
19 matches
Mail list logo
