On 2024-05-04 16:03, Collin Funk wrote:
I noticed in your emacs/output.0 it says "Generated by GNU Autoconf 2.71".
I was using Autoconf 2.72 on my system.
Ah, I am using Autoconf 2.71, which is what's in /usr/bin/autoconf on
Fedora 40. It comes from the autoconf-2.71-10.fc40.noarch package,
On 5/4/24 8:17 AM, Bruno Haible wrote:
>> For CI, I am thinking it is best to ignore the typing warnings for the
>> time being. Since gnulib-tool.py needs a bit more refactoring for that
>> to be helpful. It was written before typing was a thing. :)
>
> Hmm. Is that refactoring, that you are
Hi Paul,
On 5/4/24 3:02 PM, Paul Eggert wrote:
> On 2024-05-04 13:45, Collin Funk wrote:
>> I can't reproduce this (using Fedora 40).
>
> That's odd, as I just now reproduced it on Fedora 40 x86-64 using the
> following from-scratch recipe:
I noticed in your emacs/output.0 it says "Generated
On 5/4/24 3:02 PM, Paul Eggert wrote:
> The attached build log shows what I got. The last 'grep' command shows the
> bug, as lib/gnulib.mk.in uses HAVE_OFF64_T without defining it.
>
> This invocation of admin/merge-gnulib uses a nearly-empty environment and an
> empty home directory, to lessen
On 5/4/24 2:30 PM, Paul Eggert wrote:
>> But, I think the next POSIX revision has like Glibc which I
>> prefer.
>
> If the past is any guide, an advantage of the C23 version is that in
> the long run it is likely to be more portable. POSIX is an extension
> of C.
True. But I don't think C23 has
On 2024-05-04 13:45, Collin Funk wrote:
I can't reproduce this (using Fedora 40).
That's odd, as I just now reproduced it on Fedora 40 x86-64 using the
following from-scratch recipe:
mkdir new empty
empty_home=$PWD/empty
cd new
git clone git://git.sv.gnu.org/emacs.git
(cd
On 2024-05-04 13:54, Collin Funk wrote:
IIRC in there is:
#define __STDC_ENDIAN_LITTLE__ /* Unique constant */
#define __STDC_ENDIAN_BIG__ /* Unique constant */
#define __STDC_ENDIAN_NATIVE__ /* __STDC_ENDIAN_LITTLE__ or
__STDC_ENDIAN_BIG__ */
probably with values taken
Hi Bruno,
On 5/4/24 7:52 AM, Bruno Haible wrote:
> And we're not yet done with the header file substitutes. One is still missing
> from Gnulib: [1]. The only thing that has changed since last year
> is that glibc 2.39 now has this header file [2]. But who will want to use it,
> as long as it's
Hi Paul,
On 5/4/24 9:03 AM, Paul Eggert wrote:
> Some sort of locale problem? The issue seems to be benign, except that it's a
> false positive when testing.
>
> To reproduce it, clone current gnulib (commit
> fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) and current emacs (commit
>
On 2024-05-04 10:43, Bruno Haible wrote:
but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line
Strange. The AC_SUBST([HAVE_OFF64_T]) in m4/off64_t.m4 should produce
such a line.
My thought as well.
The fragile hackery is only needed because you've hit a bug
Yes. To be fair it could well
Hi Paul,
> but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line
Strange. The AC_SUBST([HAVE_OFF64_T]) in m4/off64_t.m4 should produce
such a line.
Do you see the 'sys_types' module enabled? Or maybe it is only
conditionally enabled?
> It strikes me that apps like Emacs and coreutils don't
I had problems updating Emacs to use gnulib commit
fde88b711c9b1df5b142444ac7b0bc2aa8892d3a along with emacs commit
fd859fbea2e9d13e76db1c5295d9ddd1c5955d83 (these are the same commits as
I mentioned earlier today). I reproduced it like this:
cd emacs
admin/merge-gnulib
The resulting
Hi Bruno,
Thank you for taking a look at this.
> - How do _you_ compile and run a program in this environment?
> The same way as in [2], or do you do it differently?
Yes, I use wasi-sdk[1] as described in the document. My current motivation
is porting
libidn to WebAssembly and I needed to
On 5/4/2024 10:36 AM, Bruno Haible wrote:
I'm committing this workaround.
Thanks! I've tested on Cygwin 3.5.3 and on the latest test release, and
I can confirm that the problem is fixed.
Ken
On 2024-05-04 07:52, Bruno Haible wrote:
But who will want to use it,
as long as it's not portable?
I'm working on a Gnulib that will work on pre-C23 platforms.
Eventually this should replace Gnulib's count-leading-zeros,
count-trailing-zeros, and count-one-bits modules, which should be
Some sort of locale problem? The issue seems to be benign, except that
it's a false positive when testing.
To reproduce it, clone current gnulib (commit
fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) and current emacs (commit
fd859fbea2e9d13e76db1c5295d9ddd1c5955d83) under the current directory,
Collin Funk wrote:
> For CI, I am thinking it is best to ignore the typing warnings for the
> time being. Since gnulib-tool.py needs a bit more refactoring for that
> to be helpful. It was written before typing was a thing. :)
Hmm. Is that refactoring, that you are imagining, intrusive? If it's
Hi Saito-san,
> * lib/getdtablesize.c (getdtablesize): Return INT_MAX if getrlimit
> is not available. This is the case for WASI, WebAssembly System
> Interface.
Can you please tell us more about this compilation environment?
I want to evaluate how much effort Gnulib should put into
Collin Funk wrote:
> I didn't realize the header replacements started this early. I'm a big
> fan of them.
And we're not yet done with the header file substitutes. One is still missing
from Gnulib: [1]. The only thing that has changed since last year
is that glibc 2.39 now has this header file
Ken Brown wrote:
> I don't know what's going on, but it seems clear that pagefile.sys can't
> be used reliably on Cygwin to get a boot time. I wonder if
> get_boot_time should simply bail out on Cygwin and always give a boot
> time of 0. Or do you have a better idea?
I'm committing this
* lib/getdtablesize.c (getdtablesize): Return INT_MAX if getrlimit
is not available. This is the case for WASI, WebAssembly System
Interface.
* m4/getdtablesize.m4 (gl_PREREQ_GETDTABLESIZE): Check for getrlimit.
---
ChangeLog | 8
lib/getdtablesize.c | 2 ++
On 5/4/24 3:34 AM, Bruno Haible wrote:
> Yes. We cannot change the past git log, but this is one of the situations
> where changing a ChangeLog entry is adequate. Other such situations are
> obvious typos and forgotten changes.
I've pushed the attached patch adding the date to the ChangeLog
Hi Collin,
> > Can you please add, to the first line of the ChangeLog entry, a note
> > that tells us when the regression was introduced? Such as
> >(regression 2024-xx-xy)
> > or
> >(regr. yesterday)
> ...
> I've never modified a ChangeLog entry before. Is the proper way to
> just modify
Hi Collin,
> > doc: Add appendix about Gnulib history.
> > * doc/gnulib-history.texi: New file.
> > * doc/gnulib.texi: Include it.
>
> Interesting section, thanks.
I wrote it also as an answer to misguided statements that
"gnulib is mainly about porting to non-Linux platforms" [1].
On 5/3/24 11:32 PM, Paul Eggert wrote:
> Not quite, because it doesn't check for padding bits.
Sorry, I should have clarified excluding that part...
> Also, your code assumes that preprocessor arithmetic works the same as
> runtime arithmetic. Although C23 guarantees this (because it
>
On 2024-05-03 17:14, Collin Funk wrote:
Also about this comment in intprops-internal.h:
/* This include file assumes that signed types are two's complement without
padding bits; the above macros have undefined behavior otherwise.
If this is a problem for you, please let us
26 matches
Mail list logo
