From owner-freebsd-ports@FreeBSD.ORG Wed May 7 22:24:30 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2572BAC8; Wed, 7 May 2014 22:24:30 +0000 (UTC) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 5B500805; Wed, 7 May 2014 22:24:28 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMLAJ+xalNR8aV7/2dsb2JhbABYgwZPS64CAZhHF3SCZhxfNCpSiCoBm0a0c5MYBJk2gT2RP4M2Ow Received: from 123.165-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.165.123]) by relay.skynet.be with ESMTP; 08 May 2014 00:24:22 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s47MOLba008367; Thu, 8 May 2014 00:24:21 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Thu, 8 May 2014 00:24:20 +0200 From: Tijl Coosemans To: freebsd-ports@FreeBSD.org Subject: To all port maintainers: libtool Message-ID: <20140508002420.5d37e7f6@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:24:30 -0000 Hi, I've been asked to write something about USES=libtool to clarify a few things about what it does and why. First: what is libtool? Libtool is a build script that acts as a wrapper around a compiler. You can compile code or link a library (or executable) with libtool and it will invoke the right compiler, linker and other commands for you. It supports multiple languages, compilers and platforms and simplifies writing makefiles when used in combination with automake. Many ports use it. The problems with libtool on FreeBSD. Libraries created with libtool have three version numbers X.Y.Z. How they are calculated is not straightforward but that's not important right now. The important thing is that the major version number X is the only one that really matters. An executable that links to libA will ask for libA.so.X and doesn't care about Y and Z. Only when the major version number of a library changes does everything that link to it need to be recompiled. On FreeBSD however libtool uses X+Y as major version number which means that changes in Y also require rebuilding all ports that depend on the library. A second problem is that libtool flattens the dependency tree. When you link an executable or library with libA while libA in turn links to libB then libtool will make the executable or library also link with libB. This means that when the major version number of libB changes, the executable or library will also have to be rebuilt. Some libraries get propagated into hundreds and even thousands of ports this way while only a few actually use them directly. These two problems make major version number changes too frequent and too painful, not only for users who build their own ports, but also for package users, because too many packages need to be rebuilt, mirrored and downloaded every week than strictly necessary. A third problem is with ports that have USE_AUTOTOOLS=libtool in their Makefile. Normally the libtool script is generated by the configure script so it uses the compiler, linker and other tools that you configure a port with. Ports with USE_AUTOTOOLS=libtool however use /use/local/bin/libtool. This is the libtool script generated by the configure script of devel/libtool. This mechanism was meant for ports that ship with a version of libtool that doesn't work properly, but the problem is that such ports aren't necessarily built with the same tools as devel/libtool. An upcoming feature that allows cross-building ports and that will be used to provide ARM packages is currently blocked by this because these ports don't use the right cross compiler and linker. The solution. All ports that use libtool need to have USES=libtool added to their Makefile and USE_AUTOTOOLS=libtool removed. USES=libtool will patch the port to address the problems above along with a few smaller problems with older versions of libtool that some ports still ship with. USES=libtool also replaces USE_GNOME=ltverhack so that should be removed as well. In fact, all libtool related hacks and patches that a port contains can probably be removed (typically patches or post-patch commands for files like ltconfig, ltmain.sh and configure). The easiest way to know if a port uses libtool is to build it first. You can then search the work directory for a file named "libtool": # cd some/port # make # find work -name libtool Another giveaway is the installation of files with .la extension. USES=libtool modifiers :keepla and :oldver. One of the ways libtool propagates links is through .la libraries. These are ordinary text files that contain some meta-data about a library, including a record of all dependencies. These files are normally not needed and USES=libtool removes them from the staging area. For the rare cases where a port does need these files USES=libtool:keepla can be used. In this case .la files are kept but the dependency record is cleared so dependencies won't be propagated to other ports. Another important reason to keep .la files is that in this transition period other ports may still contain references to them in the dependency record of their .la files. These ports first need to have some form of USES=libtool added to their Makefile such that these references are removed. So, as long as there are dependent ports that install .la files but do not have some form of USES=libtool, a port must use USES=libtool:keepla. Finally, because the major version number goes from X+Y to X, if Y is non-zero, the library version will go backwards. This is not a problem in the sense of API compatibility (because of the way libtool versioning works everything between X and X+Y is backwards compatible and a new release that isn't backwards compatible will see its major version number jump to newX=oldX+oldY+1), but it may be a problem if due to link propagation many ports depend on the library and they all need to get a PORTREVISION bump. To avoid this, USES=libtool:oldver can be used. A port will then continue to use the old X+Y version scheme but it will no longer propagate its own dependencies to other ports. Once enough ports use some form of USES=libtool the number of dependent ports will drop to a point that removing :oldver becomes possible. Note that USES=libtool:oldver is a transitional measure and support for it will eventually be removed.