On Thu, Mar 24, 2016 at 2:09 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Mar 24, 2016 at 12:47:51PM +0000, Dave Gordon wrote:
>> On 24/03/16 11:11, Sedat Dilek wrote:
>> > From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
>> >From: Sedat Dilek<sedat.dilek@xxxxxxxxx>
>> >Date: Thu, 24 Mar 2016 12:01:37 +0100
>> >Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
>> > automake problem
>> >
>> >---
>> > Makefile.am | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/Makefile.am b/Makefile.am
>> >index c60e8a729271..396f41fdc4df 100644
>> >--- a/Makefile.am
>> >+++ b/Makefile.am
>> >@@ -18,7 +18,7 @@
>> > # IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>> > # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> >
>> >-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>> >+ACLOCAL_AMFLAGS = -I m4
>> >
>> > SUBDIRS = man libobj xvmc src tools
>> >
>> >--
>>
>> Looks like the issue is related to trying to layer the Make-variable
>> expansion.
>>
>> In the shell (and most other languages) an assignment like:
>>
>> $ ACLOCAL_AMFLAGS="${ACLOCAL_FLAGS} -I m4"
>>
>> would take the current value of the existing ACLOCAL_FLAGS variable
>> and use it construct the value of the new variable ACLOCAL_AMFLAGS.
>> Thus if ACLOCAL_were "--XXX" this would yield "-XXX -I m4". Then
>> later we'd see:
>>
>> $ aclocal ${ACLOCAL_AMFLAGS} ...
>>
>> which would use the value as previously defined.
>>
>> Make doesn't do that. It sets ACLOCAL_AMFLAGS to "$(ACLOCAL_FLAGS)
>> -I m4" and then later, when ACLOCAL_AMFLAGS is *used* it expands it,
>> and then notices that the expanded version still contains a $(var)
>> construct and expands *that* ... and so on until there are none
>> left. This is sometimes useful, but often confusing. So GNU make (as
>> POSIX, from 2012 on) supports another type of assignment,
>>
>> VAR ::= expression
>>
>> which does the expansion of <expression> just once, at this point,
>> and stores the result rather than the <expression> itself. So, try
>> changing the line
>>
>> ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>>
>> in the Makefile into:
>>
>> ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>>
>> and see whether that helps :)
>
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> => autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
> ...
>
> With setenv ACLOCAL_FLAGS "-I /opt/xorg/share/aclocal":
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/ ${ACLOCAL_FLAGS} -I m4
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
> ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
>
> Using ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>
> It looks like using
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> is obsolete in autoreconf (GNU Autoconf) 2.69.
> So looks like the answer is
> AC_PREREQ([2.69])
> ACLOCAL_AMFLAGS = -I m4
Not sure what the real fix of the reported "ACLOCAL_FLAGS issue" is.
As said in my initial asking I have here on Ubuntu/precise AMD64 autoconf v2.68.
Being no autotools-guru, version and feature check might make sense.
- Sedat -
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
