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 <gentoo-user+bounces-54502-garchives=archives.gentoo.org@gentoo.org>)
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 <gentoo-user@lists.gentoo.org>; Thu, 9 Nov 2006 01:47:53 GMT
Received: by nf-out-0910.google.com with SMTP id c31so929568nfb
for <gentoo-user@lists.gentoo.org>; 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" <bigfish@asmallpond.org>
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: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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 <vgivanovic@comcast.net> wrote:
> On Wed, 2006-11-08 at 10:04 -0700, Richard Fish wrote:
> > On 11/8/06, Vladimir G. Ivanovic <vgivanovic@comcast.net> 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