From owner-freebsd-ports@FreeBSD.ORG Wed Mar 24 21:28:05 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81AB216A4CE for ; Wed, 24 Mar 2004 21:28:05 -0800 (PST) Received: from meitner.wh.uni-dortmund.de (meitner.wh.uni-dortmund.de [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 101B943D39 for ; Wed, 24 Mar 2004 21:28:05 -0800 (PST) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 27EEC16759B; Thu, 25 Mar 2004 06:28:04 +0100 (CET) Received: from [192.168.8.4] (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i2P5S3Wv027860 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 25 Mar 2004 06:28:03 +0100 (CET) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: Oliver Eikemeier Date: Thu, 25 Mar 2004 06:27:59 +0100 User-Agent: KMail/1.6.1 References: <200403250423.47441.michaelnottebrock@gmx.net> <406261F0.5010800@fillmore-labs.com> In-Reply-To: <406261F0.5010800@fillmore-labs.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_i3mYAMgqe5VVWtd"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403250628.02955.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: Mark Linimon cc: freebsd-ports@FreeBSD.org Subject: Re: cvs commit: ports/devel/libvanessa_adt Makefile pkg-plist ports/devel/libvanessa_adt/files patch-ltmain.sh X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2004 05:28:05 -0000 --Boundary-02=_i3mYAMgqe5VVWtd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 25 March 2004 05:37, Oliver Eikemeier wrote: > Michael Nottebrock wrote: > > [...] > > >>So far I followed the former discussions, but I can't remember an examp= le > >>where something *really* uses the .la files. > > > > Yes, although I keep repeating it, nobody seems to ever remember: KDE > > _really_ uses them, as it _really_ uses lt_dlopen(). Also third party K= DE > > applications will use them (if they happen to load modules or plugins -= a > > simple preferences dialog can be such a module for example), since they > > use kdelibs which in turn use lt_dlopen(). > > Ehm, yes, but this is a case for modules or plugins, which should be easi= ly > coordinated (since they won't be loaded otherwise). Yet the .la files are needed - if they weren't, we could just nuke them in = the=20 KDE ports. Also, the libidn-kdelibs example shows a scenario where=20 lt_dlopen() is used on a file installed by a different package. > I think this is self-evident, but if you want to state it explicit that's > fine with me. Maybe not in RFC-style, though ;) A comment in the Makefile > or packing list, stating which ports are clients of the .la files may be a > nice addition. I think something like LIBTOOLFLAGS=3D # none, we want to keep libwv2.la (taken from textproc/wv2) is probably sufficient enough to keep any=20 anti-libtool-archive crusaders away (that libtool archive is kept for koffi= ce=20 btw). The really funny thing is - I've just looked at the porter's handbook again= =20 and there simply isn't any good place to add this paragraph to, because the= re=20 is no section dealing with libtool archives or ".la files" and the why/why= =20 not/whatisitgoodforanyway at all. =46rom digging in the commitlogs I can reconstruct that the default=20 "--disable-ltlibs" argument to ltconfig was added to bsd.port.mk in revisio= n=20 1.319 (that was back in 1999) and the portlint warnings were added a few=20 months later (revision 1.30 of devel/portlint/Makefile has the commit=20 message).=20 In none of these commits/commitmessages there is any indication that anybod= y=20 was ever convinced of the fact that libtool archives were useless or unneed= ed=20 =2D they would just not be created by default for any port that defines=20 USE_LIBTOOL (at that time this probably worked - it doesn't really anymore= =20 today, extra patches and hacks are often needed - in case of textproc/wv2 a= =20 patch to the configure script), but that behaviour could and can easily be= =20 overridden by redefining LIBTOOLFLAGS (see above). Also, from what I can gather from the commit logs, USE_LIBTOOL was _not_ ad= ded=20 to bsd.port.mk to get rid of libtool archives - that 'feature' was added=20 later. This, plus the fact that nobody ever created any documentation about libtoo= l=20 archives and their (non)-uses leads me to believe that ".la files are not=20 needed on FreeBSD" really is just a legend, born out of erroneous statement= s=20 on mailing lists and the fact that ports using lt_dlopen() on=20 shared-libraries not installed by themselves are indeed quite rare and thus= =20 disproof of such claims was not readily available for everybody to observe. It's quite fascinating how the "convention" of avoiding libtool archives=20 established itself out of (almost) thin air, and how nobody ever asked "Whe= re=20 is this documented?". Until now, that is. Anyway, Mark: I will try to write up something about libtool archives,=20 libltdl, USE_LIBTOOL, lt_dlopen(), life, the universe and everything and th= en=20 condense it again so it will fit in the porter's handbook somewhere, but it= =20 might take some time - I suck at writing concise documentation. :) =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_i3mYAMgqe5VVWtd Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAYm3iXhc68WspdLARAtW5AJ9dxo92iuWzY5KD/I63F8VFGmzAUQCfVF21 FDk0skCO6sEVegsSmxDF7xA= =o3zO -----END PGP SIGNATURE----- --Boundary-02=_i3mYAMgqe5VVWtd--