Re: [gentoo-user] parrot & openoffice failures
On Thursday 09 November 2006 18:24, Graham Murray wrote: > "Richard Fish" <[EMAIL PROTECTED]> writes: > > Now if openoffice fails to build against the new icu, then _that_ is a > > bug. :-) > > The rebuild of openoffice-2.04 to build against the new icu failed for > me, but the emerge also download something. But I have not yet had > time to look and see why the build failed. > For me it was the sound element. Added a -sound to the use flags and it compiled fine. - Noven -- >-- Novensiles divi Flamen --< > Miles Militis Fons < pgp3LWWo3GEgc.pgp Description: PGP signature
Re: [gentoo-user] parrot & openoffice failures
"Richard Fish" <[EMAIL PROTECTED]> writes: > Now if openoffice fails to build against the new icu, then _that_ is a bug. > :-) The rebuild of openoffice-2.04 to build against the new icu failed for me, but the emerge also download something. But I have not yet had time to look and see why the build failed. But I have noticed this before with openoffice. A new version comes out and it builds fine. But later when revdep-rebuild wants to rebuild it, or I have run 'emerge -e world' (for example after an upgrade to gcc/libstdc++), the build has failed and each time it has also downloaded a new patch or something even though the version has not changed. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] parrot & openoffice failures
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]> -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] parrot & openoffice failures
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 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] parrot & openoffice failures
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. 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). > > > BTW, re-emerging parrot fixed parrot's problem, and I have 5 hours, 31 > > minutes and 40 seconds before I can tell you if it fixed openoffice's > > problem (I'm assuming it will). > > Now if openoffice fails to build against the new icu, then _that_ is a bug. > :-) Openoffice build successfully. > > -Richard -- Vladimir G. Ivanovic <[EMAIL PROTECTED]> -- gentoo-user@gentoo.org mailing list
[gentoo-user] parrot & openoffice failures
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? BTW, re-emerging parrot fixed parrot's problem, and I have 5 hours, 31 minutes and 40 seconds before I can tell you if it fixed openoffice's problem (I'm assuming it will). --- Vladimir -- Vladimir G. Ivanovic <[EMAIL PROTECTED]> -- gentoo-user@gentoo.org mailing list
