[gentoo-user] parrot & openoffice failures

[gentoo-user] parrot & openoffice failures

[Vladimir G. Ivanovic]

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 <vgivanovic@comcast.net>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] parrot & openoffice failures

[Richard Fish]

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.

> 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. :-)

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] parrot & openoffice failures

[Vladimir G. Ivanovic]

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.

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 <vgivanovic@comcast.net>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] parrot & openoffice failures

[Richard Fish]

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

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@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
-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] parrot & openoffice failures

[Graham Murray]

"Richard Fish" <bigfish@asmallpond.org> 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

[Novensiles divi Flamen]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Thursday 09 November 2006 18:24, Graham Murray wrote:
> "Richard Fish" <bigfish@asmallpond.org> 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 ----<

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]