bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12877: automake error: unrequested trace ''


From: Sebastian Freundt
Subject: bug#12877: automake error: unrequested trace ''
Date: Wed, 14 Nov 2012 06:45:59 +0000
User-agent: Gnus/5.130005 (Ma Gnus v0.5) SXEmacs/22.1.14 (linux)

Stefano Lattarini <address@hidden> writes:

> tags 12877 + moreinfo
> thanks
>
> Hi Sebastian, thanks for the report.
>
> On 11/13/2012 11:30 AM, Sebastian Freundt wrote:
>> shell> automake --version
>> automake (GNU automake) 1.12.1
>> 
>> autoreconf: running: automake --add-missing --copy --force-missing
>> Use of uninitialized value $macro in exists at 
>> /home/freundt/usr/bin/automake line 5267, <GEN0> line 2.
>> Use of uninitialized value $macro in concatenation (.) or string at 
>> /home/freundt/usr/bin/automake line 5267, <GEN0> line 2.
>> automake: error: unrequested trace ''
>> automake: Please contact <address@hidden>.
>>  at /home/freundt/usr/share/automake-1.12/Automake/Channels.pm line 662
>>         Automake::Channels::msg('automake', '', 'unrequested trace \'\'') 
>> called at /home/freundt/usr/share/automake-1.12/Automake/ChannelDefs.pm line 
>> 212
>>         Automake::ChannelDefs::prog_error('unrequested trace \'\'') called 
>> at /home/freundt/usr/bin/automake line 5267
>>         Automake::scan_autoconf_traces('configure.ac') called at 
>> /home/freundt/usr/bin/automake line 5533
>>         Automake::scan_autoconf_files() called at 
>> /home/freundt/usr/bin/automake line 8588
>> autoreconf: automake failed with exit status: 29
>> 
>> In project: https://quickplot.svn.sf.net/svnroot/quickplot/trunk
>> 
> I cannot reproduce this failure with the latest automake release (1.12.4).
> I've tried with both autoconf 2.69 and autoconf 2.65, just to be extra sure.
>
> Does the error disappear for you as well if you use automake 1.12.4?

Ah, I found the culprit.  But first off, the tag v1.12.4 isn't in the
savannah git repo yet.

(GNU) m4 when being called with the variable POSIXLY_CORRECT behaves
differently as all GNU extensions will be suppressed.

I recently populated this var in my shell setup because coreutils need it
to work around some SysV quirks.

So the workaround of the day (mostly a note to myself) is to unset
POSIXLY_CORRECT temporarily when dealing with autotools.

Cheers
Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]