On 16 Apr 2025, at 15:56, Ross Burton <ross.bur...@arm.com> wrote:
>
> On 16 Apr 2025, at 15:00, Frederic Berat via Discussion list for automake
> <automake@gnu.org> wrote:
>>
>> On Fri, Apr 11, 2025 at 7:09 PM Karl Berry <k...@freefriends.org> wrote:
>>
>>> This is to announce automake-1.17.92, a alpha release.
>>> See the NEWS below for a brief summary of changes.
>>>
>>> Download here:
>>> https://alpha.gnu.org/gnu/automake/automake-1.17.92.tar.gz
>>> https://alpha.gnu.org/gnu/automake/automake-1.17.92.tar.xz
>>>
>>> Hello,
>>
>> I've massively rebuilt Fedora packages that depend on automake with this
>> new release, and didn't notice any problem so far.
>
> I repeated my tests and rebuilds of existing source trees that have been
> configured with 1.70 still break for me:
>
> configure:2611: error: possibly undefined macro: AM_RUN_LOG
>
> I’m doing builds now with old, new, and rebuild, to compare and contrast.
Reverting 2d2ff6070ca13428032c14f1d1cfd57b6b22e42d (use ustar by default) makes
this go away.
I know we discussed this a bit before but I’ll reiterate it. Using intltool as
a test simply because its the first thing that broke in my build and its low on
dependencies if I:
1. build intltool out-of-tree from a fresh tarball with automake 1.17.0
2. delete the build tree, autoreconf the same source tree with 1.17.92
Then I get AM_RUN_LOG errors. It’s not wrong: aclocal.m4 is missing AM_RUN_LOG
which should be pulled in via the ustar checks that are added to aclocal.m4.
The broken aclocal.m4 looks like this:
# tar/untar a dummy directory, and stop if the command works.
rm -rf conftest.dir
mkdir conftest.dir
echo GrepMe > conftest.dir/file
AM_RUN_LOG(tardir=conftest.dir && eval $am__tar_ >conftest.tar)
rm -rf conftest.dir
if test -s conftest.tar; then
AM_RUN_LOG($am__untar <conftest.tar)
AM_RUN_LOG(cat conftest.dir/file)
grep GrepMe conftest.dir/file >/dev/null 2>&1 && break
fi
It feels like there’s something going wrong with the tracing. With the caveat
that I have no idea what I’m doing, I note that autom4te.cache/traces.0 in the
broken rebuild case is exactly identical to the 1.17.0 build , and different to
the 1.17.92 clean build. traces.1 and traces.2 however are different between
.0 and .92, and the same in the clean and dirty 1.17.92 builds.
This then leads to a the confused output.1 and output.2 with the ustar checking
code, minus AM_RUN_LOG expansion.
I will happily poke further to identify where this is going wrong if anyone has
a good idea…
Ross
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
