On 24/03/16 12:47, Chris Wilson wrote:
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
Perhaps try setting AC_CONFIG_MACRO_DIRS to [/opt/xorg/share/aclocal,
m4] instead, and not use ACLOCAL_AMFLAGS? Or at least not to extend the
include path.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
