Red Hat Bugzilla – Bug 239093
OpenOffice.org2 will not install on x86_64: missing dependency libcrux-engine.so
Last modified: 2013-01-10 05:18:45 EST
Description of problem:
OO.o2 will not install on x86_64 (through up2date) because it is missing a
dependency: libcrux-engine.so. gnome-themes includes the library, but it is
found in /usr/lib64/gtk-2.0/2.4.0/engines/libcrux-engine.so (lib64). Since OO.o
is i386, it expects the library in /usr/lib/...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. up2date openoffice.org2-core
Unresolvable chain of dependencies:
openoffice.org2-core 2.0.4-5.7.0 requires libcrux-engine.so
Is there some reason that we don't have an x86_64 version of OO.o2?
I don't see that there's a bug here for me to fix, this is a i386 OOo so it
needs an i386 gnome-themes not an x86_64 gnome-themes. They should be
installable in parallel. The dependency chain should have pulled in a 32bit gtk
stack from gnome-themes downwards.
An x86_64 RHEL-4 OOo2 2.0.4 was not provided because there was no x86_64 OOo
1.1.X for RHEL-4, and because the state of e.g. 64bit java/gcj on RHEL-4 is even
more of a mess than the 32bit java RHEL-4 world
I agree that this is really a RHN bug. Which compontent should I change it to
so the RHN folks can look at this?
Thanks for the information (and the laugh) about 64-bit OOo.
You only have the 64bit gnome-themes installed in the above afaics, What happens
if you repeat the above test after installing gnome-themes-2.8.0-1.i386 ?
That just enables building the native x86_64 OOo port which I considered too
experimental and too much effort to build for RHEL-4 even for the tech preview.
Since an x86_64 native build is going to be such a problem then perhaps a
change to the spec file for OOo by adding gnome-themes-2.8.0-1.i386
would make more sense ?
At least it does for me.
Issue escalated to RHEL 4 Desktop by: alanm.
Internal Status set to 'Waiting on Engineering'
This event sent from IssueTracker by alanm
I was just able to successfully install OO.o2 on x86_64. The dependency issues
seem to be resolved.
Oops, I mistakenly ran it on an i386 system. x86_64 is still broken. Here are
the new dependency errors:
Unresolvable chain of dependencies:
openoffice.org2-core 2.0.4-188.8.131.52.0 requires libcrux-engine.so
openoffice.org2-core 2.0.4-184.108.40.206.0 requires libnspr4.so
openoffice.org2-core 2.0.4-220.127.116.11.0 requires libnss3.so
openoffice.org2-core 2.0.4-18.104.22.168.0 requires libplc4.so
openoffice.org2-core 2.0.4-22.214.171.124.0 requires libplds4.so
openoffice.org2-core 2.0.4-126.96.36.199.0 requires libsmime3.so
openoffice.org2-core 2.0.4-188.8.131.52.0 requires libsoftokn3.so
openoffice.org2-core 2.0.4-184.108.40.206.0 requires libssl3.so
this needs to be assigned to the right owner so that it doesn't get lost. As
this not an up2date issue, I'm not the right owner for this bug.
Could you please assign this to whoever owns openoffice.org ?
There is no bug in the OOo rpms AFAICS, there was no native x86_64 OOo2 rpm
provided, and a Requires on libcrux-engine.so was inserted deliberately to
ensure that if the 32bit OOo2 was installed on 64bit that the necessary but
otherwise not auto-required runtime 32bit dependencies are pulled in.
Apparently they are not being pulled in on RHEL-4 because the required 32bit
packages are not automatically available on the 64bit channel. I know nothing
about how all that works, but comment #5 looks sort of the right thing.
Of course I could always enable building the 64bit OOo (i.e. #6 and #9) which I
guess sidesteps some of this foo and confusion, and I'm tempted to do that if we
ever have to otherwise respin the OOo2 for RHEL-4.
Since the root issue appear to be a missing mulitlib package, I'm reassigning
this bug to myself and changing the component to comps.
re: Caolan, what do you think?
sure, dropping emailmerge and pyuno is no biggy for the tech preview from my POV
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.