On 5/4/24 10:54 PM, Paul Eggert wrote:
>> 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, which is the
> current version for Fedora 40.
>
> Occasionlly I use ble
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,
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 by
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 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 e
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
> fd859fbea2e9d1
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,
a
