Bug 87162

Comment 1 Thierry Thomas 2005-10-10 21:03:00 UTC

Responsible Changed
From-To: freebsd-ports-bugs->ade


Assign to maintainer.

Comment 2 Ade Lovett 2005-10-11 02:00:01 UTC

State Changed
From-To: open->closed

This is not how the versioned autotools, which are used for port building, 
actually work.  If you look at ports/Mk/bsd.autotools.mk, you'll notice 
that a whole slew of environmental variables get set which tell the tools 
where to find their files. 

In the context of the USE_AUTOTOOLS framework within a port Makefile, 
the tools operate quite well -- at least as well as can be expected, to 
allow for mixing and matching of the specific versions needed to build 
ports that require the use of autotools, as can be seen from the package 
building clusters.

On Tue, Oct 11, 2005 at 01:03:14AM +0000, Ade Lovett wrote:
> Synopsis: devel/libtool15 installs aclocal files in wrong place?
> 
> State-Changed-From-To: open->closed
> State-Changed-By: ade
> State-Changed-When: Tue Oct 11 01:00:01 GMT 2005
> State-Changed-Why: 
> This is not how the versioned autotools, which are used for port building,
> actually work.  If you look at ports/Mk/bsd.autotools.mk, you'll notice
> that a whole slew of environmental variables get set which tell the tools
> where to find their files.
> 
> In the context of the USE_AUTOTOOLS framework within a port Makefile,
> the tools operate quite well -- at least as well as can be expected, to
> allow for mixing and matching of the specific versions needed to build
> ports that require the use of autotools, as can be seen from the package
> building clusters.

Thank you for the response; I'm not actually building a port though [*].

Looking at the Makefile you highlighted made me think that

  LIBTOOL_M4=/usr/local/share/aclocal/libtool15.m4; export LIBTOOL_M4

might do the trick. However that doesn't work. Removing my symlink
workarounds first, this is what happens:

    [brian@billdog bdbobj]$ LIBTOOL_M4=/usr/local/share/aclocal/libtool15.m4; export LIBTOOL_M4
    [brian@billdog bdbobj]$ LIBTOOL=/usr/local/bin/libtool15; export LIBTOOL
    [brian@billdog bdbobj]$ LIBTOOLIZE=/usr/local/bin/libtoolize15; export LIBTOOLIZE
    [brian@billdog bdbobj]$ LIBTOOL_SHAREDIR=/usr/local/share/libtool15; export LIBTOOL_SHAREDIR
    [brian@billdog bdbobj]$ LTCONFIG=${LIBTOOL_SHAREDIR}/ltconfig15; export LTCONFIG
    [brian@billdog bdbobj]$ automake19 --foreign --add-missing
    Makefile.am:14: Libtool library used but `LIBTOOL' is undefined
    Makefile.am:14: 
    Makefile.am:14: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
    Makefile.am:14: to `configure.in' and run `aclocal' and `autoconf' again.
    [brian@billdog bdbobj]$ autoconf259
    configure.in:19: error: possibly undefined macro: AC_PROG_LIBTOOL
          If this token and others are legitimate, please use m4_pattern_allow.
          See the Autoconf documentation.

In fact, the variable LIBTOOL_M4 doesn't seem to be referenced anywhere
from the autoconf/automake/libtool packages:

    [brian@billdog bdbobj]$ pkg_info -L auto\* | xargs grep LIBTOOL_M4
    [brian@billdog bdbobj]$ pkg_info -L libt\* | xargs grep LIBTOOL_M4

which makes me wonder what on earth this variable is supposed to do.

So I'm rather stuck. I think you'll agree that these tools are a pain in the
butt at the best of times, and having to reverse-engineer them to try to
find why they don't work out-of-the-box when installed from FreeBSD ports
is something I'm not enjoying.

Perhaps a comment in the pkg-descr would be helpful, explaining what you
have to do to make them work in the way FreeBSD packages them. All it
currently says is:

    Description:
    This is GNU Libtool, a generic library support script.  Libtool hides
    the complexity of using shared libraries behind a consistent, portable
    interface.

    To use libtool, add the new generic library building commands to your
    Makefile, Makefile.in, or Makefile.am.

    WWW: http://www.gnu.org/software/libtool/

which implies to me that they should just work. If you have to frob some
environment variables for them to work under FreeBSD then I consider it a
documentation bug at least; I don't expect to have to go hunting for them.

Regards,

Brian.

[*] This software happens to be courier-authlib and courier-imap from their
CVS repositories. If I were building the released version then it would be
in a nice tarball with all the autoconf stuff already run.

Comment 4 Ade Lovett 2005-10-11 18:55:12 UTC

On Oct 11, 2005, at 02:23 , Brian Candler wrote:
> Thank you for the response; I'm not actually building a port though  
> [*].

If you're not building a port, then you should be using the gnu-  
versions of the autotools in devel.

 From the top of ports/Mk/bsd.autotools.mk:

# The "versioned" autotools referenced here are for BUILDING other ports
# only.  THIS CANNOT BE STRESSED HIGHLY ENOUGH.  Things WILL BREAK if  
you
# try to use them for anything other than ports/ work.  This  
particularly
# includes use as a run-time dependency.
#
# If you need unmodified versions of autotools, such as for use in an
# IDE, then you MUST use the devel/gnu-* equivalents, and NOT these.
# See devel/anjuta and devel/kdevelop for examples.
#
# You have been WARNED!

-aDe

On Tue, Oct 11, 2005 at 10:55:12AM -0700, Ade Lovett wrote:
> # The "versioned" autotools referenced here are for BUILDING other ports
> # only.  THIS CANNOT BE STRESSED HIGHLY ENOUGH.  Things WILL BREAK if  
> you
> # try to use them for anything other than ports/ work.  This  
> particularly
> # includes use as a run-time dependency.
> #
> # If you need unmodified versions of autotools, such as for use in an
> # IDE, then you MUST use the devel/gnu-* equivalents, and NOT these.
> # See devel/anjuta and devel/kdevelop for examples.
> #
> # You have been WARNED!

Ack - thanks. I still think a warning in the the pkg-descr would be good, as
without your help I wouldn't have found this.

Regards,

Brian.

On Tue, Oct 11, 2005 at 10:55:12AM -0700, Ade Lovett wrote:
> If you're not building a port, then you should be using the gnu-  
> versions of the autotools in devel.

Ah. Now someone needs to notify the maintainer of the 'sysconftool' package
of this.

# pkg_info -L sysconftool\*
Information for sysconftool-0.15:

Files:
/usr/local/man/man1/sysconftool.1.gz
/usr/local/man/man1/sysconftoolcheck.1.gz
/usr/local/man/man7/sysconftool.7.gz
/usr/local/bin/sysconftoolize
/usr/local/bin/sysconftoolcheck
/usr/local/share/aclocal19/sysconftool.m4            <<<<<<
/usr/local/share/sysconftool/sysconftool
/usr/local/share/sysconftool/sysconftoolize.pl
/usr/local/share/sysconftool/sysconftoolcheck
/usr/local/share/sysconftool/sysconftoolize.am

The indicated file needs to be installed as

/usr/local/gnu-autotools/share/aclocal/sysconftool.m4
or perhaps
/usr/local/gnu-autotools/share/aclocal-1.9/sysconftool.m4

if it is to work with the devel/gnu-* packages, since they have

PREFIX?=        ${LOCALBASE}/gnu-autotools

Regards,

Brian.