From owner-freebsd-ports@FreeBSD.ORG Wed May 7 23:16:41 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 8C1B6A76; Wed, 7 May 2014 23:16:41 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E949CBED; Wed, 7 May 2014 23:16:40 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so169480wib.3 for ; Wed, 07 May 2014 16:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pGmw2X6u6StaDO49Ld3Hr3mDMlosxOtIxSn8orCTwXA=; b=b7vzDPN0/LzZN3IJkC2lLWCgf1ljrfR0MI0qYjf1gukjjitYnW9UmMmAi5C5sY+edR ewGR2UUJlsqlwEFYL7DJP5Xuz+l21gl5DQrrP9J2B4+fN7sy1OhFD4MpG0nOIb4vvrNe U6kPzosv+0uLW01V7CltwluWGvQaOo0KW9kZeBFWWIrm6I59zVyxWNmADOzXQj5M5a/A bitE+CdadCLZoVq2wUmW46TMRcJrqnEL5pbkaKAxYLSGOh3PG4ds/s7lLMboflzNHH31 BESN9ySAPejseaQRGw/EmIVcLK9BxvuF2eP75QfqS4Ngwesutdlkc8f3skHWJwOwABb6 C3EQ== X-Received: by 10.180.8.66 with SMTP id p2mr9905386wia.37.1399504599125; Wed, 07 May 2014 16:16:39 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id l12sm28279817wjr.35.2014.05.07.16.16.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 May 2014 16:16:38 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 8 May 2014 01:16:36 +0200 From: Baptiste Daroussin To: Tijl Coosemans Subject: Re: To all port maintainers: libtool Message-ID: <20140507231636.GB55396@ivaldir.etoilebsd.net> References: <20140508002420.5d37e7f6@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <20140508002420.5d37e7f6@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports@FreeBSD.org 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 23:16:41 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 08, 2014 at 12:24:20AM +0200, Tijl Coosemans wrote: > Hi, >=20 > I've been asked to write something about USES=3Dlibtool to clarify a few > things about what it does and why. >=20 >=20 > First: what is libtool? >=20 > 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 wi= ll > 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. >=20 >=20 > The problems with libtool on FreeBSD. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > A third problem is with ports that have USE_AUTOTOOLS=3Dlibtool 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=3Dlibtool 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. >=20 >=20 > The solution. >=20 > All ports that use libtool need to have USES=3Dlibtool added to their > Makefile and USE_AUTOTOOLS=3Dlibtool removed. USES=3Dlibtool 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=3Dlibtool > also replaces USE_GNOME=3Dltverhack 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). >=20 > 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": >=20 > # cd some/port > # make > # find work -name libtool >=20 > Another giveaway is the installation of files with .la extension. >=20 >=20 > USES=3Dlibtool modifiers :keepla and :oldver. >=20 > 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=3Dlibtool removes them from the staging area. For the ra= re > cases where a port does need these files USES=3Dlibtool:keepla can be use= d. > In this case .la files are kept but the dependency record is cleared so > dependencies won't be propagated to other ports. >=20 > 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=3Dlibtool 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=3Dlibtool, a port must use > USES=3Dlibtool:keepla. >=20 > 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=3DoldX+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=3Dlibtool: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=3Dlibtool the number of dependent ports will > drop to a point that removing :oldver becomes possible. Note that > USES=3Dlibtool:oldver is a transitional measure and support for it will > eventually be removed. Thank you very much for this write up! and for all your work helping us solving a very long standing major problem in the ports tree! regards, Bapt --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlNqvtQACgkQ8kTtMUmk6ExaQwCfXb1m/6+W6s9DRwPTqAvj7iH4 nkAAn0KDBbgnPzxwzNs7gNBJs+u9EOmB =pYmO -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4--