On 11/8/06, Vladimir G. Ivanovic <[EMAIL PROTECTED]> wrote:
On Wed, 2006-11-08 at 10:04 -0700, Richard Fish wrote:
> On 11/8/06, Vladimir G. Ivanovic <[EMAIL PROTECTED]> 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
--
[email protected] mailing list
