Automake is not compatible with older Autoconfs we provide

  • Open
  • quality assurance status badge
Details
3 participants
  • Ekaitz Zarraga
  • Giovanni Biscuolo
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Ekaitz Zarraga
Severity
normal
E
E
Ekaitz Zarraga wrote on 12 Dec 2023 16:00
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
c922a420-03ef-7781-5016-5174930ce81f@elenq.tech
Hi,

We have automake packaged, but it's not compatible with older autoconf
versions so autoconf is not very usable at this point.

```
Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell
automake autoconf@2.64
Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv) [env]$
autoreconf -vif
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I . -I .. -I ../config
configure.ac:74: error: Autoconf version 2.65 or higher is required
/gnu/store/p0c4zj5na8w9hpsp5v5h637wnybx0hb6-automake-1.16.5/share/aclocal-1.16/init.m4:29:
AM_INIT_AUTOMAKE is expanded from...
configure.ac:74: the top level
autom4te: /gnu/store/n3kxhwi5qdil1vlaq5b6zwyiv7wkrw76-m4-1.4.19/bin/m4
failed with exit status: 63
aclocal: error: autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63
```

Is this only my thing?
M
M
Maxim Cournoyer wrote on 12 Dec 2023 17:59
(name . Ekaitz Zarraga)(address . ekaitz@elenq.tech)(address . 67796@debbugs.gnu.org)
87edfrbbmp.fsf@gmail.com
Hi,

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

Toggle quote (25 lines)
> Hi,
>
> We have automake packaged, but it's not compatible with older autoconf
> versions so autoconf is not very usable at this point.
>
> ```
> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell
> automake autoconf@2.64
> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv) [env]$
> autoreconf -vif
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force -I . -I .. -I ../config
> configure.ac:74: error: Autoconf version 2.65 or higher is required
> /gnu/store/p0c4zj5na8w9hpsp5v5h637wnybx0hb6-automake-1.16.5/share/aclocal-1.16/init.m4:29:
> AM_INIT_AUTOMAKE is expanded from...
> configure.ac:74: the top level
> autom4te: /gnu/store/n3kxhwi5qdil1vlaq5b6zwyiv7wkrw76-m4-1.4.19/bin/m4
> failed with exit status: 63
> aclocal: error: autom4te failed with exit status: 63
> autoreconf: aclocal failed with exit status: 63
> ```
>
> Is this only my thing?

'guix show automake' shows we also have automake 1.9.6 available. I
suppose this still works with the older autoconf?

--
Thanks,
Maxim
E
E
Ekaitz Zarraga wrote on 12 Dec 2023 20:47
Automake is not compatible with older Autoconfs we provide
e231e380-e316-7f8b-a3fe-6e1b0fc8b97f@elenq.tech
Maxim,

> 'guix show automake' shows we also have automake 1.9.6 available. I
suppose this still works with the older autoconf?

I don't have that automake version and I can't find it Guix's codebase.
Are you up to date with master?

Best,
Ekaitz
M
M
Maxim Cournoyer wrote on 12 Dec 2023 21:47
(name . Ekaitz Zarraga)(address . ekaitz@elenq.tech)(address . 67796@debbugs.gnu.org)
87plzb9mhr.fsf@gmail.com
Hi,

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

Toggle quote (8 lines)
> Maxim,
>
>> 'guix show automake' shows we also have automake 1.9.6 available. I
> suppose this still works with the older autoconf?
>
> I don't have that automake version and I can't find it Guix's
> codebase. Are you up to date with master?

Oh, indeed, I wasn't. Only 1.16.5 remains. I'm not sure which commit
removed it.

--
Thanks,
Maxim
G
G
Giovanni Biscuolo wrote on 11 Jan 10:42 +0100
Re: bug#67796: Automake is not compatible with older Autoconfs we provide
87mstcb40b.fsf@xelera.eu
Hi Ekaitz

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

Toggle quote (9 lines)
> Hi,
>
> We have automake packaged, but it's not compatible with older autoconf
> versions so autoconf is not very usable at this point.
>
> ```
> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell
> automake autoconf@2.64

is there a reason you need to "pin" to the 2.64 version?

[...]

Toggle quote (2 lines)
> configure.ac:74: error: Autoconf version 2.65 or higher is required

we now have autoconf-2.68 and -2.69 and autoconf is autoconf-2.69

does this solve the issue you reported?

Happy hacking, Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmWft/QMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSPVkP/jEeNxSvjWI8eqX3lLYRE82Sdr5+R5VZzAH2FQLC
byWEGIgCqqYAwhVQJP0SELo7JSQlJZrLjycpduI8x+3+GFtYAEg/cfqzNT8pCTnk
PcJzyAIYeq5Qa1/CED2rdQJVq9M1QQB9nBkfyYXC3+uQtZThNgDhP+haGQRmLVSO
HgNa6BE4DJfJBi3eb/TBMJHe55oLIkP2SY2c3m92ItiekY/ODD4Wd3ub/zhHCH6V
bL4VE+A8VSn8tt8VrB+FJUctUzCTd/Jf7BcVSNdW8UZYloG3GjS3s8JydDYV9VaR
GphkLCqQfSVhuxEb2n9eGd8DDUCYzm7qHy82T1EoNe7oBAf97C0e+pWle7JTqZ4Z
2djG2E9kj9Lhfj6Ap6SFl+6htuLo6L4OsIxeQdUa8vB+mLj3V2wg2DIoCy+z8qbD
9J8qxs1p0EedJDal73OUvzTFDzvFnhzueEf5+QLLscXL9pm+dn3SnhzaMsm8Kd+U
ydvgEpGY6bj21wupj4gitw6s+RuxQklYyeiTBEBa5hlXtfsYFAphKdQ2kGc3nFwv
7bZAwFDTtiruMJtBBnFUYBKxzKIkrjQr8gUMB3OT36b+t7sPAowFgjvcOsYk95+i
axCEgZY44Ndd4WA7+fuxz+4s6Cg4d3Yh53c6w9zNOA/3SUEosLV3FsKN1fltDtNb
I/Lh
=ETOY
-----END PGP SIGNATURE-----

E
E
Ekaitz Zarraga wrote on 11 Jan 11:40 +0100
86a3869a-0968-3c30-45e7-1f493dcbb63c@elenq.tech
Hi,
On 2024-01-11 10:42, Giovanni Biscuolo wrote:
Toggle quote (14 lines)
> Hi Ekaitz
>
> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>
>> Hi,
>>
>> We have automake packaged, but it's not compatible with older autoconf
>> versions so autoconf is not very usable at this point.
>>
>> ```
>> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell
>> automake autoconf@2.64
>
> is there a reason you need to "pin" to the 2.64 version?
I had one, I was working on GCC bootstrapping... It's not a big deal if
we just remove the older versions.
The problem I wanted to make us notice is we were keeping the 2.64
version and we didn't really provide any compatible automake, so the
autoconf@2.64 was almost useless.
If no package uses those, it's ok to remove. I can always time-machine
around the problem.
Thanks!
Attachment: OpenPGP_signature
G
G
Giovanni Biscuolo wrote on 12 Jan 19:38 +0100
87h6jibdnk.fsf@xelera.eu
Hi,

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

[...]

Toggle quote (11 lines)
>>> We have automake packaged, but it's not compatible with older autoconf
>>> versions so autoconf is not very usable at this point.
>>>
>>> ```
>>> Ekaitz@tuxedo ~/projects/nlnet/gcc/libstdc++-v3 (riscv)$ guix shell
>>> automake autoconf@2.64
>>
>> is there a reason you need to "pin" to the 2.64 version?
>
> I had one, I was working on GCC bootstrapping...

oh OK :-)

Toggle quote (2 lines)
> It's not a big deal if we just remove the older versions.

but if they are needed for bootstrapping they should be kept around, no?

Toggle quote (4 lines)
> The problem I wanted to make us notice is we were keeping the 2.64
> version and we didn't really provide any compatible automake, so the
> autoconf@2.64 was almost useless.

I'm not very familiar with Autoconf and Automake (nor with
bootstrapping): is there a "compatibility table" around? I quickly had
a look to the respective manuals but I was not able to find one.

Toggle quote (3 lines)
> If no package uses those, it's ok to remove. I can always time-machine
> around the problem.

OK old packages can always (almost) be time-machined back but if they
are needed for bootstrapping (for sexample if your work on GCC
bootstrapping is succesful) they should be in Guix proper, no?

is this a bug? :-)

Thanks for your work! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmWhhx8MHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSL/sQAMRAbRGYMAvpU7gJ2+BUhQ4HB4w3rPhNh+0ngg3K
7jtKf8DpWNEZQjvXlhh0NJkKrsLk5r/2KPw2PGVnuMhGXJ6Kmh39YreU1IlgMa9a
G7vJWcPzmQHx+KauZBqzcfXJx3e5h/D1NnLc7bmdfkFH7m/E8iNcO0wcbjZ8aW+7
VtLyEdW2hupp805rw7xbw+q2hI//6q/qytajVCxs6YhgjBPRiIEpviWJsEbU9DHL
0/8amsSLJnTrcZ+1eKD9fXWwVSirkRslM1jcWgir8ik81pV7ypVgKeuAuS483rJr
4r+9qVNNTgDRidQCkFJUo7lev/6yPsXdJ2uypvHXi2aSORJeTWiXruYiNIjT6CQ2
dddckmD6lqw8SQyxRwvfR/2DPYsA0JYab/jo5tdQDEtgULY8xb9wVAISAIwA8Mm0
/Ah7yQq14N83LCB/qX9U/vnob1zpYFkxSUfQMFGZjuWwIP3ePEZFvedeujNALe2J
aXGWXFvmBo05Z9/L0d1+b9NVV5T7ALi9BgPxCFbp4McHDzCW1gI0j2VWma+vDV7+
ZmCz+A5NO9fPQkRZHCUqH2B7iMa46/PBVJ2M9WHR3pTCEfuUV1Q8+EUc2tWv0K7t
biva5ZVYPoVDvdzZ7X594M4FjS128hBCv+E+mgFvuQ+oNO/Ojp7rLzdrmdL6iK9G
zIrs
=yrDa
-----END PGP SIGNATURE-----

E
E
Ekaitz Zarraga wrote on 12 Jan 19:53 +0100
2a4834ce-1289-6eb2-e104-53f320a235d4@elenq.tech
Hi,


On 2024-01-12 19:38, Giovanni Biscuolo wrote:

Toggle quote (4 lines)
>> It's not a big deal if we just remove the older versions.
>
> but if they are needed for bootstrapping they should be kept around, no?

No, because they are not needed for the bootstrapping itself. We build
stuff from scratch for it, I needed them to rebuild the configure
scripts on GCC, which I don't need to rebuild anymore (GCC's codebase
includes the configure scripts prebuilt). That's where I realized.

Toggle quote (8 lines)
>> The problem I wanted to make us notice is we were keeping the 2.64
>> version and we didn't really provide any compatible automake, so the
>> autoconf@2.64 was almost useless.
>
> I'm not very familiar with Autoconf and Automake (nor with
> bootstrapping): is there a "compatibility table" around? I quickly had
> a look to the respective manuals but I was not able to find one.

I don't know either. I tried to use the 2.64 one and that told me the
Automake wasn't compatible.

Toggle quote (9 lines)
>> If no package uses those, it's ok to remove. I can always time-machine
>> around the problem.
>
> OK old packages can always (almost) be time-machined back but if they
> are needed for bootstrapping (for sexample if your work on GCC
> bootstrapping is succesful) they should be in Guix proper, no?
>
> is this a bug? :-)

The problem in my opinion is including a 2.64 autoconf that we can't run
actually use for the lack of a compatible automake. Not providing it is
a better option. I don't need it for bootstrapping recipes, and if I
need it in the future I'll remake the package.

If Autoconf 2.64 is not needed by any package my proposal is to remove
it from Guix and let the people interested on it to `time-machine`, as
that's going to probably have the correct automake with it.

Toggle quote (2 lines)
> Thanks for your work! Gio'

Thank you!
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 67796@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 67796
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch