From nobody@FreeBSD.org  Fri May 27 14:16:57 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CB69616A41C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 May 2005 14:16:57 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id AA7C943D48
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 May 2005 14:16:57 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j4REGvTq055825
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 27 May 2005 14:16:57 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j4REGvgk055824;
	Fri, 27 May 2005 14:16:57 GMT
	(envelope-from nobody)
Message-Id: <200505271416.j4REGvgk055824@www.freebsd.org>
Date: Fri, 27 May 2005 14:16:57 GMT
From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: AC_PROG_LIBTOOL macro is not available to automake
X-Send-Pr-Version: www-2.3

>Number:         81558
>Category:       ports
>Synopsis:       devel/libtool15: AC_PROG_LIBTOOL macro is not available to automake
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 27 14:20:01 GMT 2005
>Closed-Date:    Sat May 28 11:15:11 GMT 2005
>Last-Modified:  Sun May 29 22:20:02 GMT 2005
>Originator:     Markus Hoenicka
>Release:        5.4-RELEASE
>Organization:
>Environment:
FreeBSD yeti.mininet 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Wed May 25 23:01:46 CEST 2005     markus@yeti.mininet:/usr/src/sys/i386/compile/YETI  i386
>Description:
If configure.in calls the AC_PROG_LIBTOOL macro, the command sequence
libtoolize15 --force --copy
aclocal19 --force
autoheader259
automake19 --add-missing --force-missing
autoconf259

fails to build a usable configure script. The error message indicates that the AC_PROG_LIBTOOL and AC_PROG_LD macros cannot be expanded:

configure.in:27: error: possibly undefined macro: AC_PROG_LD
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:29: error: possibly undefined macro: AC_PROG_LIBTOOL

In order to exclude version problems of the autotools, I've removed libtool13 which was installed as a dependency. The system was otherwise a fresh install and had installed only the autotools versions mentioned above.

>How-To-Repeat:
I've noticed this problem while trying to build the current cvs version of libdbi (http://refdb.sourceforge.net/projects/libdbi)

Please note that in the current cvs version the ./autogen.sh file must be edited to use the appropriate autotools version, as indicated above. Or just run the commands listed in the full description.
>Fix:
root@yeti:/usr/local/share/aclocal19# ln -s ../aclocal/libtool15.m4 libtool15.m4
      
>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@freebsd.org>
To: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
Cc: bug-followup@freebsd.org
Subject: Re: misc/81558: AC_PROG_LIBTOOL macro is not available to automake
Date: Fri, 27 May 2005 17:33:14 +0300

 On 2005-05-27 14:16, Markus Hoenicka <markus.hoenicka@mhoenicka.de> wrote:
 > If configure.in calls the AC_PROG_LIBTOOL macro, the command sequence
 >
 > libtoolize15 --force --copy
 > aclocal19 --force
 > autoheader259
 > automake19 --add-missing --force-missing
 > autoconf259
 >
 > fails to build a usable configure script. The error message
 > indicates that the AC_PROG_LIBTOOL and AC_PROG_LD macros cannot be
 > expanded:
 >
 > configure.in:27: error: possibly undefined macro: AC_PROG_LD
 >       If this token and others are legitimate, please use m4_pattern_allow.
 >       See the Autoconf documentation.
 > configure.in:29: error: possibly undefined macro: AC_PROG_LIBTOOL
 
 I don't think using the autoconfXXX and automakeXXX ports for software
 that builds outside of the Ports is supported.  Please use the
 devel/gnu-autoconf, devel/gnu-automake and devel/gnu-libtool ports
 for this sort of thing.  These will install full versions of the
 autotools in /usr/local/gnu-autotools and can be used by setting the
 PATH to point first to /usr/local/gnu-autotools/bin and then to
 /usr/local/bin.
 
 - Giorgos
 
Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri May 27 19:37:34 GMT 2005 
Responsible-Changed-Why:  
Reclassify as a ports bug.  Note that I really can't tell exactly 
which port is affected so I picked one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=81558 

From: "Markus Hoenicka" <markus.hoenicka@mhoenicka.de>
To: Giorgos Keramidas <keramida@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: misc/81558: AC_PROG_LIBTOOL macro is not available to automake
Date: Fri, 27 May 2005 23:52:12 +0200

 Ok I'll try that. Please excuse my ignorance.
 Thanks
 Markus
 
 Giorgos Keramidas writes:
  > I don't think using the autoconfXXX and automakeXXX ports for software
  > that builds outside of the Ports is supported.  Please use the
  > devel/gnu-autoconf, devel/gnu-automake and devel/gnu-libtool ports
  > for this sort of thing.  These will install full versions of the
  > autotools in /usr/local/gnu-autotools and can be used by setting the
  > PATH to point first to /usr/local/gnu-autotools/bin and then to
  > /usr/local/bin.
  > 
 
 -- 
 Markus Hoenicka
 markus.hoenicka@cats.de
 (Spam-protected email: replace the quadrupeds with "mhoenicka")
 http://www.mhoenicka.de
 
State-Changed-From-To: open->closed 
State-Changed-By: pav 
State-Changed-When: Sat May 28 11:14:48 GMT 2005 
State-Changed-Why:  
Yup, gnu-* versions of autotools should work 

http://www.freebsd.org/cgi/query-pr.cgi?pr=81558 

From: "Markus Hoenicka" <markus.hoenicka@mhoenicka.de>
To: Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc: bug-followup@freebsd.org
Subject: Re: misc/81558: AC_PROG_LIBTOOL macro is not available to automake
Date: Sun, 29 May 2005 21:51:55 +0200

 Hi,
 
 Giorgos Keramidas writes:
  > > The symptoms are:
  > > - automake --add-missing --force-missing fails to install
  > >   mkinstalldirs in the sources if there is no conf subdir.
  > >   Manually copying the file fixes the build problem. If there is a
  > >   conf subdirectory, a symlink is created properly
  > 
  > I think automake looks for an option in configure.ac and puts the files
  > in the directory specified there.  The ports version of gnu-automake is
  > relatively old though and may be broken.
  > 
 
 I couldn't find a macro that would specifically control which files
 are installed in the source tree. I'll investigate further before I
 claim this is a bug.
 
  > Does the same thing happen with newer versions of automake too?  I've
  > been using automake-1.9.x for a while now, so it may be worth testing to
  > see if newer versions fix this problem and asking the port maintainers
  > to update the version installed by the port.
  > 
 
 Well, all I can say that it didn't happen with older automake
 versions.
 
  > > - the /usr/local/gnu-autotools/share/aclocal directory is next to
  > >   empty. If a package like the Iconv stuff installs m4 macros, they
  > >   end up in /usr/local/share/aclocal and are therefore not available
  > >   to the gnu version of aclocal. I know that aclocal has an --acdir
  > >   option but this is not useful for writing portable autogen.sh or
  > >   bootstrap.sh scripts.
  > 
  > Hmmm, this is a problem indeed.  One that cannot be fixed by using a
  > prefix different from /usr/local :-(
  > 
 
 Would that qualify as a bug? From my point of view this problem
 renders the gnu-autotools packages pretty useless. I don't know about
 the backgrounds of the split between bsd autotools and gnu autotools,
 but I'd prefer to have one set of autotools on the system. Otherwise
 the gnu autotools should be integrated into the installation
 procedures of autotools-related packages.
 
 Should I file a bug report about this problem?
 
 regards,
 Markus
 
 -- 
 Markus Hoenicka
 markus.hoenicka@cats.de
 (Spam-protected email: replace the quadrupeds with "mhoenicka")
 http://www.mhoenicka.de
 

From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
Cc: bug-followup@freebsd.org
Subject: Re: misc/81558: AC_PROG_LIBTOOL macro is not available to automake
Date: Mon, 30 May 2005 01:16:42 +0300

 On 2005-05-29 21:51, Markus Hoenicka <markus.hoenicka@mhoenicka.de> wrote:
 >Giorgos Keramidas writes:
 >>> The symptoms are:
 >>> - automake --add-missing --force-missing fails to install
 >>>   mkinstalldirs in the sources if there is no conf subdir.
 >>>   Manually copying the file fixes the build problem. If there is a
 >>>   conf subdirectory, a symlink is created properly
 >>
 >> I think automake looks for an option in configure.ac and puts the files
 >> in the directory specified there.  The ports version of gnu-automake is
 >> relatively old though and may be broken.
 >
 > I couldn't find a macro that would specifically control which files
 > are installed in the source tree. I'll investigate further before I
 > claim this is a bug.
 
 The AC_CONFIG_AUX_DIR() macro sets the directory where autoconf and
 automake will look for "auxiliary build tools".  This is, in my
 experience, where autotools will install all helper files too, when
 the --copy option is used.
 
 >>> - the /usr/local/gnu-autotools/share/aclocal directory is next to
 >>>   empty. If a package like the Iconv stuff installs m4 macros, they
 >>>   end up in /usr/local/share/aclocal and are therefore not available
 >>>   to the gnu version of aclocal. I know that aclocal has an --acdir
 >>>   option but this is not useful for writing portable autogen.sh or
 >>>   bootstrap.sh scripts.
 >>
 >> Hmmm, this is a problem indeed.  One that cannot be fixed by using a
 >> prefix different from /usr/local :-(
 >
 > Would that qualify as a bug? From my point of view this problem
 > renders the gnu-autotools packages pretty useless. I don't know about
 > the backgrounds of the split between bsd autotools and gnu autotools,
 > but I'd prefer to have one set of autotools on the system.
 
 It would probably qualify as a bug.  Unless the ports that need to find
 autotools can be taught to use autoconf magic to detect at install time
 where their autoconf related macros should be installed.
 
 > Should I file a bug report about this problem?
 
 I'm not sure.  The maintainer of the gnu-auto* ports should be contacted
 first, since my experience with autotools is strictly limited to the
 absolutely necessary parts that are needed for my dayjob.  I mostly
 avoid autotools when I can ;-)
 
 
>Unformatted:
