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

Eric Blake <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.patches
Organization Red Hat, Inc.
Message-ID <[email protected]>
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 protected]>
>> ---
>>  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
signature.asc (application/pgp-signature, 619 B)
-----BEGIN PGP SIGNATURE-----
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAloCBKoACgkQp6FrSiUn
Q2ok8gf9FzHXw73STgXkaDiYps2cH88mF3Xwa2KRsLpc3TRHqAM+/+e1i8qPoGzZ
/x7EV/v/B+cNsmO1mCt9b6q/O2GbPx57TFP7kfLfMnXcQBXhmxA59kboh5VQp7QT
JSMOBU4s2GdZDOsqAemoGlO4soaDoCovIwgxfc1I0xGlbX9wiYalHrn7WBnq/Ean
DEW34g66F/Dk+8kgELhN7uB71NvnwQcsUkAFqg4epG0MDZIZRK8Fp1Sg381L3fAW
j1tASRWRwWqjTJl9uRepm4906gVZG3LuDuXvMsbcxiUeMpb3je11lChJo/WqyAio
oBe9NW77AuBtY0w0rAAbFwJVRxxmlw==
=VDin
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.