| Message ID | CA+icZUWOHgTK2kQQFzgK7M3OrY8DDJDM6Pu0nQmHzn4uO8i-rQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 24/03/16 11:11, Sedat Dilek wrote: > From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001 > From: Sedat Dilek<sedat.dilek@gmail.com> > 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 :) .Dave.
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@gmail.com> > >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 -Chris
On Thu, Mar 24, 2016 at 2:09 PM, Chris Wilson <chris@chris-wilson.co.uk> 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@gmail.com> >> >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 -
From 1f951b5d65bc9b5b78606f06025a78facd5b402d Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.dilek@gmail.com> Date: Thu, 24 Mar 2016 12:05:25 +0100 Subject: [PATCH 3/3] configure: Remove unused common libc routines check --- configure.ac | 3 --- 1 file changed, 3 deletions(-) diff --git a/configure.ac b/configure.ac index 0457d52c04df..840fb3d96947 100644 --- a/configure.ac +++ b/configure.ac @@ -62,9 +62,6 @@ AC_DISABLE_STATIC AC_PROG_LIBTOOL AC_SYS_LARGEFILE -# Check for common libc routines redefined by os.h -AC_CHECK_FUNCS([strlcpy strlcat strndup], [], []) - # Platform specific settings case $host_os in *linux*) -- 2.7.4