Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jun 2003 17:59:34 -0500
From:      Ade Lovett <ade@lovett.com>
To:        ports@FreeBSD.org
Cc:        Ade Lovett <ade@freebsd.org>
Subject:   libtool uber-patch committed
Message-ID:  <DA5CE27F-A829-11D7-B6FD-000A956B6386@lovett.com>

next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As you will see from recent logs, the libtool uber patch has now been 
committed.

The main area for confusion going forward, and also the reason that 
this took longer than expected to finish, is that in this new world 
order, ${LOCALBASE}/bin/libtool now DOES NOT EXIST.  At all.  It's 
gone.  Dead.

Each libtool versioned port now installs in ${LOCALBASE}/bin with the 
version number (eg: libtool13, libtool14, etc..), along with various 
extensions (when using USE_LIBTOOL) to provide extra PATH entries so 
that references to 'libtool' in a port still work.

There are a couple of ports that (bizarrely) require libtool to build 
and/or run, but fail miserably with just USE_LIBTOOL etc.  These can be 
worked around with one or both of the following:

	LIBTOOLFILES=	# none

and/or

	do-configure:
		@${DO_NADA}

Suggestions for some kind of knob to more easily automate this (if 
appropriate) welcome.

The patches have been extensively tested on both my cluster, and the 
4-exp bento cluster.  Basic testing of each versioned libtool port has 
also been carried out on -CURRENT, but no more than that, since my 
ability to run port building on a -CURRENT cluster is somewhat hampered 
by lack of resources.

If there are any remaining bogons associated with the patch, they're 
usually pretty obvious "can't find /foo/bar/libtool" is the most common 
one, but there are more subtle ones.  BEFORE filing a PR say "Ade, you 
idiot, your libtool patch broke <xyz>", PLEASE check with bento to see 
if the port actually built prior to the patch going in.

Going forward, expect to see libtool 1.5.x in the tree shortly after a 
repo-copy from libtool 1.4.x, then followed by some work to do the same 
hackery to autoconf and automake.

Once that's done, the (extensive) "gnutools" magic in Mk/bsd.port.mk 
will be stripped out into a Mk/bsd.gnutools.mk (bikeshedding over the 
actual name will be gleefully ignored :), followed further by an 
OpenBSD-esque system, also somewhat inspired by our very own GNOME 
team, to collapse the myriad of USE_* variables relating to "core" GNU 
tools into something along the lines of "USE_GNUTOOLS= foo bar baz"

One final thing.  There is one minor known problem with the libtool 
ports as they stand, namely the fact that the GNU info files do not 
seem to be going into the texinfo 'dir' file correctly -- you'll see 
warnings on package deinstalls etc.  If anyone happens to have the 
necessary foo to fix this, please send it to me directly 
(ade@FreeBSD.org), and I'll test and get it in.

Enjoy.

- -aDe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQE++3rdyU/cQOgwliERAn9YAJ0aXWyPhanE6wq3mhZGkiWFvgtmzgCgi+fW
beUq3ll1UEcsfosRdUc5+K4=
=xngd
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA5CE27F-A829-11D7-B6FD-000A956B6386>