Re: [gentoo-user] parrot & openoffice failures

[Vladimir G. Ivanovic]

Thanks for taking the time to explain.

--- Vladimir

On Wed, 2006-11-08 at 18:47 -0700, Richard Fish wrote:
> On 11/8/06, Vladimir G. Ivanovic <vgivanovic@×××××××.net> wrote:
> > On Wed, 2006-11-08 at 10:04 -0700, Richard Fish wrote:
> > > On 11/8/06, Vladimir G. Ivanovic <vgivanovic@×××××××.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
-- 
Vladimir G. Ivanovic <vgivanovic@×××××××.net>

-- 
gentoo-user@g.o mailing list