GNU bug report logs - #79974
31.0.50; Failed running autoconf

Previous Next

To reply to this bug, email your comments to 79974 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Müller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Sam James <sam <at> gentoo.org>
Subject: 31.0.50; Failed running autoconf
Date: Tue, 09 Dec 2025 11:23:43 +0100

The most recent version of master fails when running autoconf:

 * Running eautoreconf in '/tmp/portage/app-editors/emacs-31.0.9999/work/emacs' ...
 * Running 'aclocal -I m4 --system-acdir=/tmp/portage/app-editors/emacs-31.0.9999/temp/aclocal' ...
 [ ok ]
 * Running 'autoconf -I m4 --force' ...
 [ !! ]
 * Failed running 'autoconf'!

autoconf says this:

'''
***** autoconf *****
***** PWD: /tmp/portage/app-editors/emacs-31.0.9999/work/emacs
***** autoconf -I m4 --force

configure.ac:3286: error: possibly undefined macro: gl_ALIGNASOF
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
'''

Bisecting points to this commit:

commit 4990849514899d1f4c7c8e4d92f83b0e1f62d95e
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date:   Mon Dec 8 18:05:13 2025 -0800

    Move Gnulib configuration back to where it was
    
    * configure.ac: Move the gl_INIT call back to where it was,
    as Mattias Engdegård reported the following problem:
      checking whether pthread_sigmask is a macro... no
      ./configure: line 32767: test: =: unary operator expected
    because moving gl_INIT up made the check for pthread_sigmask’s
    availability appear later than Gnulib’s check whether it’s a macro.
    Instead of moving gl_INIT up, call gl_ALIGNASOF earlier,
    as that’s the only part of gl_INIT that is needed earlier.

Message #8 received at 79974 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulrich Müller <ulm <at> gentoo.org>
Cc: 79974 <at> debbugs.gnu.org, Sam James <sam <at> gentoo.org>
Subject: Re: 31.0.50; Failed running autoconf
Date: Tue, 9 Dec 2025 09:41:03 -0800

On 2025-12-09 02:23, Ulrich Müller wrote:
> The most recent version of master fails when running autoconf:
> 
>   * Running eautoreconf in '/tmp/portage/app-editors/emacs-31.0.9999/work/emacs' ...
>   * Running 'aclocal -I m4 --system-acdir=/tmp/portage/app-editors/emacs-31.0.9999/temp/aclocal' ...
>   [ ok ]
>   * Running 'autoconf -I m4 --force' ...
>   [ !! ]
>   * Failed running 'autoconf'!
> 
> autoconf says this:
> 
> '''
> ***** autoconf *****
> ***** PWD: /tmp/portage/app-editors/emacs-31.0.9999/work/emacs
> ***** autoconf -I m4 --force
> 
> configure.ac:3286: error: possibly undefined macro: gl_ALIGNASOF

When I run ./autogen.sh I do not see this problem on Fedora 42 with 
current Emacs master (commit 47073fa12d149200169c921a805bde1750ca635c). 
gl_ALIGNASOF is defined in m4/stdalign.m4, just as it has been since 
Emacs commit 04d97e76a96854a9a9f4778cb1202a87537731de dated 2023-02-04.

I can't run your recipe directly as I don't have eautoconf. But my guess 
is that your recipe isn't building aclocal.m4 correctly.

I see that your recipe ran eautoconf rather than running ./autogen.sh as 
documented in Emacs's INSTALL.REPO file. If you need to run autoconf in 
a special way for Gentoo, one possibility is to have your recipe run 
./autogen.sh before the recipe does its special tailoring with 
eautoconf. That should generate an aclocal.m4 that defines gl_ALIGNASOF.

Message #11 received at 79974 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Müller <ulm <at> gentoo.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Ulrich Müller <ulm <at> gentoo.org>, 79974 <at> debbugs.gnu.org,
 Sam James <sam <at> gentoo.org>
Subject: Re: 31.0.50; Failed running autoconf
Date: Tue, 09 Dec 2025 19:42:37 +0100

>>>>> On Tue, 09 Dec 2025, Paul Eggert wrote:

> When I run ./autogen.sh I do not see this problem on Fedora 42 with
> current Emacs master (commit
> 47073fa12d149200169c921a805bde1750ca635c). gl_ALIGNASOF is defined in
> m4/stdalign.m4, just as it has been since Emacs commit
> 04d97e76a96854a9a9f4778cb1202a87537731de dated 2023-02-04.

> I can't run your recipe directly as I don't have eautoconf. But my
> guess is that your recipe isn't building aclocal.m4 correctly.

Gentoo's eautoreconf basically runs aclocal and autoconf:
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/autotools.eclass#n220

> I see that your recipe ran eautoconf rather than running ./autogen.sh
> as documented in Emacs's INSTALL.REPO file. If you need to run
> autoconf in a special way for Gentoo, one possibility is to have your
> recipe run ./autogen.sh before the recipe does its special tailoring
> with eautoconf. That should generate an aclocal.m4 that defines
> gl_ALIGNASOF.

AFAICS autogen.sh generates aclocal.m4 by concatenating "m4_include"s
for all files in the m4 directory. If I compare (diff -U0) the resulting
file with the file generated by aclocal, I see that the latter misses
some of them:

--- aclocal.m4.autogen
+++ aclocal.m4
@@ -0,0 +1,14 @@
+# generated automatically by aclocal 1.18.1 -*- Autoconf -*-
+
+# Copyright (C) 1996-2025 Free Software Foundation, Inc.
+
+# This file is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS], [])m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])])
@@ -25 +38,0 @@
-m4_include([m4/explicit_bzero.m4])
@@ -90 +102,0 @@
-m4_include([m4/pid_t.m4])
@@ -110 +121,0 @@
-m4_include([m4/st_dm_mode.m4])
@@ -113 +123,0 @@
-m4_include([m4/stdalign.m4])
@@ -147 +156,0 @@
-m4_include([m4/vararrays.m4])
@@ -150 +158,0 @@
-m4_include([m4/year2038.m4])

Shouldn't these be identical, considering that the comment in line 252
of autogen.sh says "Build aclocal.m4 here so that autoreconf need not
use aclocal." (which sounds like it's intended just as a shortcut)?

What am I missing?

Message #14 received at 79974 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulrich Müller <ulm <at> gentoo.org>
Cc: 79974 <at> debbugs.gnu.org, Sam James <sam <at> gentoo.org>
Subject: Re: 31.0.50; Failed running autoconf
Date: Tue, 9 Dec 2025 11:19:54 -0800

On 2025-12-09 10:42, Ulrich Müller wrote:
> Shouldn't these be identical, considering that the comment in line 252
> of autogen.sh says "Build aclocal.m4 here so that autoreconf need not
> use aclocal." (which sounds like it's intended just as a shortcut)?

They should be identical, but evidently the Gentoo recipe that uses 
eautoconf is screwing up. Possibly this is because it's using a bad 
cache. Possibly it's because eautoreconf installs some older-version 
files that overwrite what Emacs supplies. Or maybe it's because 
eautoreconf is using some other Automake-related tool that messes things 
up (Emacs does not use Automake).

What happens if you run ./autogen.sh instead of eautoreconf, but do 
everything else the same? If that works, you could make that change to 
Gentoo's recipe for Emacs. Or if it doesn't work, perhaps we could 
change autogen.sh so that it works better in Gentoo's build environment.

By the way, I'm puzzled that this problem is being noticed only now.

Message #17 received at 79974 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Müller <ulm <at> gentoo.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Ulrich Müller <ulm <at> gentoo.org>, 79974 <at> debbugs.gnu.org,
 Sam James <sam <at> gentoo.org>
Subject: Re: 31.0.50; Failed running autoconf
Date: Tue, 09 Dec 2025 20:36:27 +0100

>>>>> On Tue, 09 Dec 2025, Paul Eggert wrote:
>> Shouldn't these be identical, considering that the comment in line 252
>> of autogen.sh says "Build aclocal.m4 here so that autoreconf need not
>> use aclocal." (which sounds like it's intended just as a shortcut)?

> They should be identical,

Well, they aren't.

> but evidently the Gentoo recipe that uses eautoconf is screwing up.

Nope, the diff in my previous comment was against aclocal.m4 generated
by plain aclocal. No Gentoo specific tools involved there.

Message #20 received at 79974 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulrich Müller <ulm <at> gentoo.org>
Cc: 79974 <at> debbugs.gnu.org, Sam James <sam <at> gentoo.org>
Subject: Re: 31.0.50; Failed running autoconf
Date: Tue, 9 Dec 2025 18:08:12 -0800

[Message part 1 (text/plain, inline)]

On 2025-12-09 11:36, Ulrich Müller wrote:
> Nope, the diff in my previous comment was against aclocal.m4 generated
> by plain aclocal. No Gentoo specific tools involved there.

OK, thanks, I think I see the problem now. I installed the attached hack 
to work around the problem.

In the long run it will be better if Gentoo uses ./autogen.sh to do the 
automatic generation, rather than invoking the autotools by hand. This 
is because autogen.sh does several things and it's a matter of luck as 
to whether you can get by without them.

[0001-Work-even-if-aclocal-is-invoked-by-hand.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.