On Thu, Mar 24, 2016 at 12:29:32PM +0000, Dave Gordon wrote:
> 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
Yes. The issue is that recently libtool spits out
an obtuse error if it sees ${ACLOCAL_FLAGS} in ACLOCAL_AMFLAGS
libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
autoreconf: libtoolize failed with exit status: 1
i.e. it misses that we both include the user aclocal directory as well
as our own -I m4.
So I tried using it as a make variable instead, but then it is evaluated
as the shell $() command!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
