From owner-freebsd-ports@FreeBSD.ORG Tue Dec 25 11:19:16 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA1511E1 for ; Tue, 25 Dec 2012 11:19:16 +0000 (UTC) (envelope-from lumiwa@gmail.com) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by mx1.freebsd.org (Postfix) with ESMTP id 759448FC0A for ; Tue, 25 Dec 2012 11:19:16 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id y25so6463217iay.33 for ; Tue, 25 Dec 2012 03:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=EKQLZFbQE2TwZ9uQpp40XeTP9oy23OgyO5+RkO0PNNg=; b=HRpiuuiBLm/P0CeNaSUGiaCk0PupcYaA+vPuQ+OkhZzoE277CWblt7tUByycnW9ioE 6xNSdhIGazKUWleqJy5OmcwEZXzuHTQG4BHB2GJcSDCZLN8pK2dukrQ410e+jteKMPon 1vyuhIkUqB6+m0GJvmrGragUMwm7cip4gEuuUcuYOhZxMiNcGwagCkvwqrXiGZHWcKl0 svYqKzOutM94x44xvKhClvoi8d/edxFEzFeo5ABPKn2kk30+MKt+6dxwFXnp3qBB/lV/ CWGrpHn9aA0ae5eath6FBqCjQ8rTtIbxjq4JPmM1nEBOocd0pG62gDtlrjGvPLc8jzBZ btLg== X-Received: by 10.50.190.234 with SMTP id gt10mr22136500igc.73.1356434349950; Tue, 25 Dec 2012 03:19:09 -0800 (PST) Received: from luna.wi.rr.com (cpe-184-58-138-79.wi.res.rr.com. [184.58.138.79]) by mx.google.com with ESMTPS id s20sm19107955igs.10.2012.12.25.03.19.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2012 03:19:09 -0800 (PST) From: ajtiM To: Kevin Oberman Subject: Re: dependencies Date: Tue, 25 Dec 2012 05:18:58 -0600 User-Agent: KMail/1.13.7 (FreeBSD/9.1-RC3; KDE/4.8.4; i386; ; ) References: <201212241104.59921.lumiwa@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201212250518.59246.lumiwa@gmail.com> Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 11:19:16 -0000 On Monday 24 December 2012 15:08:29 Kevin Oberman wrote: > On Mon, Dec 24, 2012 at 9:04 AM, ajtiM wrote: > > Hi! > > > > I update pcre, icu...on FreeBSD 9.1 RC-3 with success, I ran as I read in > > /usr/ports/UPDATING: portmaster -o net/openldap24-sasl-client openldap24- > > client looks like successful too but if I run > > portmaster --check-depends than I got some ports (inkscape, gimp and some > > more) which missed openldap24-client. > > But if I run pkg_libchk -o everything is okay. > > I rebuilt gvfs and py-gimp but after portmaster --check-depends those two > > ports still missed openldap24-client. I am using GIMP a lot and I don't > > have any problems... > > > > I use new pkng and I have in /etc/make.conf WITH_PKGNG=yes. Almost > > everything is built with clang. > > We often are misusing the term "dependency". here, or at least > over-loading it.. A dependency, in the ports sense, is when some other > port is required to build or run another. One common dependency is on > sharable libraries (.so), but they are only a portion of what show up > as dependencies. > > To work, sharables need a fixed Application Binary Interface (ABI) so > that the routines in the library can be called from another program. > That is, the entry points in the .so file must not change or the > calling program is likely to crash or behave in an undefined manner. > All of this is mapped into the executable at link time with the > current version of the .so. Since the mapping is created when the > executable is linked, the library should change in a manner that does > not change any entry points or passed variables, changes can be made > to the library without the already built executable being impacted. > This happens fairly often and is of little note. > > Sometimes an update changes the API, often by things like changing > arguments used or completely replacing routines. If the old API is > maintained, the calling program needs no changes, but it must be > re-linked so that al of the references are updated to match the new > ones in the ABI. This is normally done by incrementing the version of > the .so. Since this version is passed to the calling program at link > time, the code that "connects" the program (rtld) to the .so will only > load the .so if the version is unchanged. If that version cannot be > located by rtld, the program exits with an error. > > In practical terms,this means that when an ABI is changed, every > program that is directly linked to this .so must be re-linked. This > almost always means that it must be re-built as we normally don't > retain all of the .o files to allow re-linking. If the old .so is > retained, programs linked to it will still work, but just keeping the > old .so around is not the solution.It is, at best, a band-aid. > \ > The problem is that a program my link to two of more libraries that > also link to the same .so. An example would be a multimedia tool that > links to a whole bunch of decoders and codecs. It may link directly to > libpng and indirectly by linking to a .so that is, itslef inked to > libpng. Or it may link to two .so's that link to libpng. In either > case, the actual executable can only load one, so if some things are > linked to .so.4 and some to .so.5, irtld will fail and exit. > > So retaining old sharables is not a solution, but can make life a bit > easier. It is still important to try to re-build all ports that link > to the library that has had its version changed as soon as possible. > > pkg_libchk "walks" through the packing list of each port and then uses > objdump to get a list of sharables used by that file and checks that > all are in the LD_LIBRARY_PATH, deliberately ignoring the files in > /usr/local/lib/compat, to provide a list of files or ports with > missing .so files.These are all dependencies of the port, but they are > only a sub-set of all dependencies or that port. But these > dependencies are all that need to be rebuilt to restore normal > operation. this is often a much smaller number of ports than the list > of ports that depend on the library. > > Many details are missing from this discussion and I probably made an > error or two. The man pages for ldconfig, pkg_libchk, rtld, and others > go into more detail on how the loading of sharables works. It is a > part of an article on this that I hope to post to the FreeBSD wiki in > a few days if other things don't get in the way, > > I know what "portmaster --check-depends" does in the case of the old > pkg database, but things would be done a bit differently for pkgng, so > I really can't explain exactly what you are seeing there. Brian might > be able to explain that. Thank you very much!! Mitja -------- http://www.redbubble.com/people/lumiwa