From owner-freebsd-ports@FreeBSD.ORG Fri Jun 4 13:35:10 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F2C106564A for ; Fri, 4 Jun 2010 13:35:10 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5998FC14 for ; Fri, 4 Jun 2010 13:35:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id A9C7F90518; Fri, 4 Jun 2010 15:35:07 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xmmYEvHxrA4m; Fri, 4 Jun 2010 15:35:07 +0200 (CEST) Received: from pc861.math.uni-hamburg.de (pc861.math.uni-hamburg.de [134.100.222.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 8389090507; Fri, 4 Jun 2010 15:35:07 +0200 (CEST) Message-ID: <4C09010A.7010906@janh.de> Date: Fri, 04 Jun 2010 15:35:06 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100514 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Leidinger References: <4C04CAAA.7080001@janh.de> <20100603123728.GA1605@server.vk2pj.dyndns.org> <20100603150208.19603v4b90d4jeec@webmail.leidinger.net> In-Reply-To: <20100603150208.19603v4b90d4jeec@webmail.leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports-list freebsd Subject: Re: Direct or indirect libdependencies (using the libintl.so.8 case) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:35:10 -0000 On 01/-10/63 20:59, Alexander Leidinger wrote: > Quoting Peter Jeremy (from Thu, 3 Jun 2010 > 22:37:28 +1000): > >> On 2010-Jun-01 10:54:02 +0200, Jan Henrik Sylvester wrote: >>> Yesterday, I was chasing libintl.so.8, rebuilding all ports that got >>> bumped, checking with libchk for other libintl.so.8 dependencies, and >>> forcing a rebuild of all these packages: All but two of them had an >>> indirect dependency on devel/gettext (and I did email the maintainers of >>> devel/ccrtp and textproc/gsed linking without a dependency). >> >> This might be unrealistic but, IMHO, these "indirect dependencies" should >> not exist. IMHO, there should only be two situations: >> >> 1) Port X directly links against or dlopen's libY.so from port Y. >> >> In this case, port Y should be listed in LIB_DEPENDS or equivalent >> for port X and port X will need a portrevision bump and rebuild if >> the port Y ABI changes (eg a .so version bump) >> >> 2) Port X directly links against or dlopen's libZ.so and libZ.so pulls >> in libY.so from port Y. >> >> In this case, port X should not be directly accessing any symbols in >> libY.so. If the libY.so ABI changes, libZ.so will need to be rebuilt >> but unless the libZ.so ABI changes, there should be no need to rebuild >> port X. >> >> Are there any other situations that have to be considered? > > The problem is a little bit more complex if you have a look at the big > picture. > > Indirect dependencies get hardcoded into binaries in several cases(*1), > except you use a compiler switch which tells the compile-time-linker to > not record library dependencies when no symbols of those libs are > reference directly(*2). > > If you want to know which libs are linked into binaries of a port, I > suggest you have a look at my > /usr/ports/Tools/scripts/explicit_lib_depends.sh script (note that its > name starts with "explicit", not with "direct", this is on purpose as > those two descriptions have a different semantic which is important for > this discussion). > > (*1) Either by libtool as it does not has some hint enabled on FreeBSD, > or by pkg-config listing them directly even if the corresponding library > does not reference symbols of such a dependency in its API. > > (*2) This is used by some gnome ports (not all), and can not be enabled > globally, as some programs may depend upon this (e.g. when loading > plugins which are not linked correctly). Thanks for your reply and blog posting. With direct and indirect, I was refering to package dependencies and not library dependencies. I have checked one of the missing dependencies with explicit_lib_depends.sh, but it did not show up, because explicit_lib_depends.sh makes some assumptions upon were binaries reside that are not true in this case: %objdump -x /usr/local/share/examples/telepathy-qt4/call/.libs/call | grep NEEDED | grep intl NEEDED libintl.so.9 %pkg_info -W /usr/local/share/examples/telepathy-qt4/call/.libs/call /usr/local/share/examples/telepathy-qt4/call/.libs/call was installed by package telepathy-qt4-0.3.2 %/usr/ports/Tools/scripts/explicit_lib_depends.sh telepathy-qt4-0.3.2 WARNING: your libtool records dependencies recursively, you can not trust the following output. QtCore:${PORTSDIR}/devel/qt4-corelib QtDBus:${PORTSDIR}/devel/dbus-qt4 QtNetwork:${PORTSDIR}/net/qt4-network QtXml:${PORTSDIR}/textproc/qt4-xml USE_GNOME+= _glib20 (devel/glib20) USE_GNOME+= libxml2 (textproc/libxml2) gstinterfaces-0.10:${PORTSDIR}/multimedia/gstreamer-plugins gstreamer-0.10:${PORTSDIR}/multimedia/gstreamer telepathy-farsight:${PORTSDIR}/net-im/telepathy-farsight telepathy-glib:${PORTSDIR}/net-im/telepathy-glib Thus, explicit_lib_depends.sh cannot be relied upon what to rebuild, either -- it missed the same that libchk does. Anyhow, this does not matter at all to the main point I tried to raise: Should _all_ explicit and direct dependencies (to use your vocabulary) be accounted for in the LIBDEPENDS of a port? The LIBDEPENDS are used to bump PORTREVISIONs to trigger rebuilds. Not having all explicit and direct dependencies listed there, reduces the use of PORTREVISION bumps so much that their negative side effect (at least when they are not done at the same moment as the original commit) becomes dominant (people relying on libchk, bsdadminscripts, or the like are forced to rebuild ports that are already consistent). Peter seems to be of my opinion by what he said above, marcus@ did introduce USE_GETTEXT for many ports that already have indirect port dependencies, so I assume that he agrees, too. On the other hand, pav@ (who is among portmgr) seems to disagree (at least a year ago), as I stated in my first mail: http://lists.freebsd.org/pipermail/cvs-ports/2009-May/172173.html And he is not the only one with that opinion. Yes, the architecture of ports is insufficient for a good solution of any kind, but as long as there is not even an agreement, what LIBDEPENDS are supposed to contain, following port updates is harder than it should be, because of the different strategies used to bump shared libraries that affect many ports. Considering the few responses my posting got, either not many see the need to reach an agreement or the posing was not clear or not concise enough. (It is not the first time I tried to raise this issue.) Cheers, Jan Henrik