[Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found

[Dave Gordon]

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.