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 <[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 -- Vladimir G. Ivanovic <[EMAIL PROTECTED]> -- [email protected] mailing list
