Subject: Re: bug#25740: [PATCH] Swallow m4traces that have no file/line number

From: Eric Blake <[email-masked]>
Date: Tue, 7 Nov 2017 13:08:26 -0600

Reviving an old thread:

On 03/08/2017 01:45 AM, Christophe de Dinechin wrote:

>>> The root cause is m4 traces without a file/line number shown.
>>>
>>> So instead of something like:
>>>
>>>   m4trace:configure.ac:48: -1- ...
>>>
>>> you have something like:
>>>
>>>  m4trace: -1- ...
>>>

>>> +++ b/bin/autom4te.in
>>> @@ -821,6 +821,8 @@ EOF
>>>   my $traces = new Autom4te::XFile ($tcache . $req->id, "<");
>>>   while ($_ = $traces->getline)
>>>     {
>>> +      # Traces without file/line
>>> +      next if (m{^m4trace: -(\d+)- ([^(]+)\((.*)$});
>>
>> Would it be better to keep the error message, but set the file and line
>> to placeholders, instead of completely discarding the message?
> 
> I had tried, and that works too in my case. I.e. you can use if this seems to be better:
> 
>> Subject: [PATCH 2/2] Alternate fix for #25740 (error reporting mangles
>>  messages)
>>
>> The symptoms are something like:
>>
>>   Use of uninitialized value $msg in concatenation (.) or string at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032.
>>   Use of uninitialized value $stacktrace in pattern match (m//) at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032.
>>   unknown channel m4trace: -1- AS_VAR_APPEND(ac_configure_args, " '$ac_arg'")
>>    at /usr/local/Cellar/autoconf/2.69/share/autoconf/Autom4te/Channels.pm line 638.
>>       Autom4te::Channels::msg('m4trace: -1- AS_VAR_APPEND(ac_configure_args, " \'$ac_arg\'")\x{a}', undef, 'warning: ', 'partial', 0) called at /usr/local/Cellar/autoconf/2.69/bin/autom4te line 1032
>>
>> The root cause is m4 traces without a file/line number shown.
>>
>> So instead of something like:
>>
>>    m4trace:configure.ac:48: -1- ...
>>
>> you have something like:
>>
>>   m4trace: -1- ...
>>
>> In the scenarios I ran into, this is due to some error that throws m4 out.
>> Eliminating these messages from the temporary m4 file being generated
>> (which will not complete anyway) is sufficient for the rest of autoconf
>> to complete, until it prints errors.
>>
>> In my case, the final error looks like:
>>
>>   common/Makefile.am:20: error: Libtool library used but 'LIBTOOL' is undefined
>>   common/Makefile.am:20:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
>>   common/Makefile.am:20:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
>>   common/Makefile.am:20:   If 'LT_INIT' is in 'configure.ac', make sure
>>   common/Makefile.am:20:   its definition is in aclocal's search path.
>>   autoreconf: automake failed with exit status: 1
>>
>> But I've seen various reports for other root causes that ran into the same
>> problem (see bug report)
>>
>> Signed-off-by: Christophe de Dinechin <[email-masked]>
>> ---
>>  bin/autom4te.in | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/bin/autom4te.in b/bin/autom4te.in
>> index b3f3831..406ebfe 100644
>> --- a/bin/autom4te.in
>> +++ b/bin/autom4te.in
>> @@ -821,8 +821,6 @@ EOF
>>    my $traces = new Autom4te::XFile ($tcache . $req->id, "<");
>>    while ($_ = $traces->getline)
>>      {
>> -      # Traces without file/line
>> -      next if (m{^m4trace: -(\d+)- ([^(]+)\((.*)$});
>>        # Trace with arguments, as the example above.  We don't try
>>        # to match the trailing parenthesis as it might be on a
>>        # separate line.
>> @@ -831,6 +829,8 @@ EOF
>>        # Traces without arguments, always on a single line.
>>        s{^m4trace:(.+):(\d+): -(\d+)- ([^)]*)\n$}
>>         {AT_$4([$1], [$2], [$3], [$4])\n};
>> +      s{^m4trace: -(\d+)- ([^(]+)\((.*)$}
>> +       {AT_$2([nowhere], [0], [$1], [$2], $3};

Yes, I like this approach better.  I really need to find time to get
autoconf 2.70 out the door...

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org