On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or noticed for the first time, here on
Ubuntu/precise AMD64)...
$ zgrep -A1 -B1 ACLOCAL_FLAGS:
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: configure.ac: tracing
--
libtoolize: copying file `m4/lt~obsolete.m4'
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: running: /usr/bin/autoconf
What does this mean and it is ignore-able?
libtool vs automake. Haven't found the right fix yet.
If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
I think that's what we'll have to do :|
-Chris
Is this a confusion between an (undefined) Make-variable vs a shell
variable? The syntax above with parentheses $(VAR) would be right for
expanding a Make-variable, but it looks like it's being passed as-is to
the shell, which interprets it as command-substitution and tries to run
the (non-existent) *command* ACLOCAL_FLAGS
Try prefixing your top-level building command (make, or ./configure, or
whatever) with the assignment ACLOCAL_FLAGS= thus:
$ ACLOCAL_FLAGS= make
Note the space after the equal-sign; this sets ACLOCAL_FLAGS to the null
string in the environment of the "make" command (only).
To get more information on what aclocal is doing, consider
$ ACLOCAL_FLAGS='--verbose' make
If those don't help, check where aclocal is being invoked and see
whether it should read "aclocal ${ACLOCAL_FLAGS}" with *braces* rather
than parentheses!
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
