Date: Wed, 7 May 2014 17:09:37 -0700 From: "Chad J. Milios" <milios@ccsys.com> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Tijl Coosemans <tijl@FreeBSD.org>, "freebsd-ports@FreeBSD.org" <freebsd-ports@FreeBSD.org> Subject: Re: To all port maintainers: libtool Message-ID: <7F488AB3-1104-4163-A5CB-06FA6FD7E0CC@ccsys.com> In-Reply-To: <20140507231636.GB55396@ivaldir.etoilebsd.net> References: <20140508002420.5d37e7f6@kalimero.tijl.coosemans.org> <20140507231636.GB55396@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 7, 2014, at 4:16 PM, Baptiste Daroussin <bapt@FreeBSD.org> wrote: >=20 >> 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 support= s >> 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 the= y >> 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 a= s >> 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 t= he >> port to address the problems above along with a few smaller problems with= >> older versions of libtool that some ports still ship with. USES=3Dlibtoo= l >> also replaces USE_GNOME=3Dltverhack so that should be removed as well. I= n >> 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. >=20 > 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! >=20 > regards, > Bapt +1 cheers hats off to ya that was both so helpful and informative. I'm so gl= ad to see that's been simplified=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7F488AB3-1104-4163-A5CB-06FA6FD7E0CC>