From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ghz5X-0005RO-0z for garchives@archives.gentoo.org; Thu, 09 Nov 2006 01:52:19 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kA91o253023974; Thu, 9 Nov 2006 01:50:02 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kA91lqq1007789 for ; Thu, 9 Nov 2006 01:47:53 GMT Received: by nf-out-0910.google.com with SMTP id c31so929568nfb for ; Wed, 08 Nov 2006 17:47:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UuHVyf7axfBLxrKXtLd5C/kvg5vtUZ2X76Ckbli3L6WkrAVvH8e4j99uQ0KJhOIoacwOV5rZt+ltAr3j3X3v3KGQT7MqtyQ46RjTSsUGmO/6hVfPfh5LQXyNpf/sLlGYogpiq5AQcd5WiDcJJWXE2fNfHvGRnO9YIh+elkX2Kvw= Received: by 10.82.109.19 with SMTP id h19mr53078buc.1163036872543; Wed, 08 Nov 2006 17:47:52 -0800 (PST) Received: by 10.82.106.3 with HTTP; Wed, 8 Nov 2006 17:47:52 -0800 (PST) Message-ID: <7573e9640611081747u1a3478d2j6e6c38a4589aec8b@mail.gmail.com> Date: Wed, 8 Nov 2006 18:47:52 -0700 From: "Richard Fish" Sender: richard.j.fish@gmail.com To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] parrot & openoffice failures In-Reply-To: <1163034822.20140.1.camel@scarlatti.leonora.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1163002848.11686.29.camel@scarlatti.leonora.org> <7573e9640611080904j9378eefn43151fc262dde568@mail.gmail.com> <1163034822.20140.1.camel@scarlatti.leonora.org> X-Google-Sender-Auth: 13e91b0dd98bc2e0 X-Archives-Salt: bf17fe9e-caf1-4874-a6d2-441012ee6305 X-Archives-Hash: 296a000ac5f0548c2d0de580580da8aa On 11/8/06, Vladimir G. Ivanovic wrote: > On Wed, 2006-11-08 at 10:04 -0700, Richard Fish wrote: > > On 11/8/06, Vladimir G. Ivanovic wrote: > > > Both parrot-0.4.6 & openoffice-2.0.4 (on AMD64) fail to run because they > > > are linked to *.so.34 versions of libraries in dev-libs/icu-3.4.1. The > > > current version is 3.6 with *.so.36 libraries. > > > > > > Is this a bug? If it is a bug, is it a bug against parrot & openoffice, > > > icu or portage? > > > > No, not a bug. This is quite normal when updating libraries on gentoo > > that some applications end up with broken dependencies. You should > > usually follow world updates with revdep-rebuild to ensure that any > > broken library dependencies get rebuilt. > > Hmmm, I thought that portage handled dependencies automatically. Not reverse library dependencies. Portage handles the case where you install pkg a that depends on libraries from pkg b. It does not handle rebuilding a when b is updated to a new (major) version. It can also use slots to keep old and incompatible versions of a library around...for example for gtk1 vs gtk2 apps. > The other thing I don't understand is why parrot and openoffice failed > in the first place. Aren't they're linked against, for example, > libicule.so? I thought the whole point of making libicule.so a symlink > to the actual library was to allow transparent library upgrades > (provided the entry points don't change). Key statement: "provided the entry points don't change". The standard convention is to link against the major version of a library, i.e. libstdc++.so.6 instead of libstdc++.so when given -lstdc++. This is because the normal convention is that incompatible library versions (fex, changes to a function arguments) require a change in the library major number. It is not uncommon to have two major versions of a library installed...you can easily have something like qt3 (libqt-mt.so.3) and qt4 (libqt-mt.so.4) at the same time with some applications that need one version and some that need the other. Minor library updates (those update the Y or Z components of libfoo.so.X.Y.Z) work as you describe...allowing a transparent upgrade of the library. BTW, this behavior is defined not by the linker itself, but by the actual libraries. When creating a shared library, the developer uses the -soname option to define what actual library name should be linked against, rather than what was specified on the linker command line. Thus, the libfoo.so link usually only serves to tell the linker what major library version to link with by default. -Richard -- gentoo-user@gentoo.org mailing list