[not really an m4 problem, so future replies can be to just automake]
On 12/08/2015 02:51 AM, Arkadiusz Miśkiewicz wrote:
>
> Hello.
>
> Using
> m4 (GNU M4) 1.4.17
> automake (GNU automake) 1.15
>
> /usr/bin/aclocal contains code:
>
> $traces .= " --language Autoconf-without-aclocal-m4 ";
> $traces = "echo '$early_m4_code' | $traces - ";
> ...
> verb "running $traces $configure_ac";
>
> my $tracefh = new Automake::XFile ("$traces $configure_ac |");
Can you try 'aclocal --verbose', to get the "running ..." output line
produced just before the failed XFile() creation attempt?
>
> which fails here:
> $ cd libgii-2.2.2; LC_ALL=C aclocal
> aclocal: error: cannot open echo 'm4_define([m4_require_silent_probe], [-])'
> |... --trace='AM_AUTOMAKE_VERSION:$f::$n' configure.ac |: No such file or
> directory
Huh - it sounds like your version of perl is trying to open a literal
file named 'echo ... | autom4te ... autoconf.ac |' , instead of properly
opening a subshell command that feeds echo to autom4te then collects the
output of autom4te (basically, Automake::XFile() is trying to do the
equivalent of a popen() on a shell command).
> Tried small script to reproduce and it also fails:
>
> #!/usr/bin/perl
>
> BEGIN {
> push ( @INC,"/usr/share/automake");
> }
>
> use strict;
>
> use Automake::XFile;
>
> my $traces = "echo 'zupa'";
> my $tracefh = new Automake::XFile ("$traces");
>
> $ LC_ALL=C perl a1.pl
> a1.pl: error: cannot open echo 'zupa': No such file or directory
Not quite the same, if you don't actually have a file named 'zupa'
handy; and particularly since the aclocal usage is trying to use perl's
open("command |") notation, not open("file") notation. Could it also be
a problem with your particular build of perl, or maybe a newer version
of perl has introduced some backwards incompatible change that
autoconf/automake now need to work with?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
