A dialogbox titled "fatal error" appears with the following message in it: "The application failed to start. loading component library failed. file:///opt/lodev4.0/program/../program/ucpgvfs1.uno.so" Operating System: Ubuntu
Did you try to uninstall completely LO (beta+LO packages from Ubuntu) then rename (or delete) LO profile and reinstall .deb?
For me that doesn't work. Added bjoern to this bug maybe he knows
I use Ubuntu 12.04 x86_64 as OS
maybe the recent switch of the --disable-gnome-vfs ./configure-switch default?
in a --disable-gnome-vfs ucpgvfs1.uno.so would not exist and neither would the component file that could cause an attempt to load it. but with --enable-gnome-vfs it's possible that the library can't be loaded because the dependencies don't exist on the system. also, this is not a Writer bug.
please try a: apt-get install libgnomevfs2-0
(eh, and report back if it helps)
I already have libgnomevfs2.0 and it doesn't help.
*** Bug 58041 has been marked as a duplicate of this bug. ***
*** Bug 57962 has been marked as a duplicate of this bug. ***
could you maybe post the output of "ldd /opt/lodev4.0//program/ucpgvfs1.uno.so"?
(In reply to comment #11) On my Ubuntu 12.04 (x86, not x86-64), linux-gate.so.1 => (0xb76e6000) libgnomevfs-2.so.0 => /usr/lib/i386-linux-gnu/libgnomevfs-2.so.0 (0xb7643000) libbonobo-activation.so.4 => not found libORBit-2.so.0 => /usr/lib/i386-linux-gnu/libORBit-2.so.0 (0xb75e8000) libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb75e3000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb75de000) libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb75db000) libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb74e2000) libcomphelpgcc3.so => /opt/lodev4.0/program/libcomphelpgcc3.so (0xb7384000) libuno_cppu.so.3 => /opt/lodev4.0/program/../ure-link/lib/libuno_cppu.so.3 (0xb7359000) libuno_cppuhelpergcc3.so.3 => /opt/lodev4.0/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 (0xb72c6000) libuno_sal.so.3 => /opt/lodev4.0/program/../ure-link/lib/libuno_sal.so.3 (0xb727b000) libuno_salhelpergcc3.so.3 => /opt/lodev4.0/program/../ure-link/lib/libuno_salhelpergcc3.so.3 (0xb7273000) libucbhelper4gcc3.so => /opt/lodev4.0/program/libucbhelper4gcc3.so (0xb7202000) libstdc++.so.6 => /opt/lodev4.0/program/../ure-link/lib/libstdc++.so.6 (0xb711a000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb70ee000) libgcc_s.so.1 => /opt/lodev4.0/program/../ure-link/lib/libgcc_s.so.1 (0xb70e3000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb70c8000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6f22000) libgconf-2.so.4 => /usr/lib/i386-linux-gnu/libgconf-2.so.4 (0xb6ef4000) libxml2.so.2 => /opt/lodev4.0/program/../ure-link/lib/libxml2.so.2 (0xb6ddd000) libdbus-glib-1.so.2 => /usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 (0xb6db7000) libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb6d6e000) libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb6d1e000) libgnutls.so.26 => /usr/lib/i386-linux-gnu/libgnutls.so.26 (0xb6c5a000) libavahi-glib.so.1 => /usr/lib/i386-linux-gnu/libavahi-glib.so.1 (0xb6c55000) libavahi-common.so.3 => /usr/lib/i386-linux-gnu/libavahi-common.so.3 (0xb6c47000) libavahi-client.so.3 => /usr/lib/i386-linux-gnu/libavahi-client.so.3 (0xb6c35000) libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb6c1c000) libutil.so.1 => /lib/i386-linux-gnu/libutil.so.1 (0xb6c18000) /lib/ld-linux.so.2 (0xb76e7000) libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6bdc000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6bd3000) libreg.so.3 => /opt/lodev4.0/program/../ure-link/lib/libreg.so.3 (0xb6bba000) libxmlreader.so => /opt/lodev4.0/program/../ure-link/lib/libxmlreader.so (0xb6baa000) libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6a53000) libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb6a4c000) libtasn1.so.3 => /usr/lib/i386-linux-gnu/libtasn1.so.3 (0xb6a3a000) libgcrypt.so.11 => /lib/i386-linux-gnu/libgcrypt.so.11 (0xb69b4000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb699e000) libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xb698c000) libstore.so.3 => /opt/lodev4.0/program/../ure-link/lib/libstore.so.3 (0xb6976000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb6957000) libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb6951000)
> libbonobo-activation.so.4 => not found Hmm, this: bjoern@beryllium:~$ apt-cache search bonobo ... libbonobo2-0 - Bonobo CORBA interfaces library ... bjoern@beryllium:~$ dpkg-query -L libbonobo2-0 ... /usr/lib/x86_64-linux-gnu/libbonobo-activation.so.4 ... tells me you need to install libbonobo2-0. Please report back, if this is the case, we would need to add a dependency for that then.
Installation of libbonobo2-0 has solved the problem. Thanks also for the details!
fixed it also for me! Thanks!
So the upstream packaging clearly needs a dep on libbonobo2-0 at least for *.deb -- possibly also for *.rpm.
Installation of libbonobo2-0 has solved the problem for me too. Thanks. Should we close the bug now?
(In reply to comment #16) > So the upstream packaging clearly needs a dep on libbonobo2-0 at least for > *.deb -- possibly also for *.rpm. the upstream RPMs at least only have dependencies on 2 or 3 libraries; i can only speculate why that is but it's likely that the reason is that the packages need to be installable on _every_ weird linux distro and the package names and/or location of the files on file system are different between different distros. ... looking at the setup_native/scripts/fake-db.spec there is this list: Provides: libgnomevfs-2.so.0 Provides: libgnomevfs-2.so.0()(64bit) Provides: libgconf-2.so.4 Provides: libgconf-2.so.4()(64bit) Provides: libfreetype.so.6 Provides: libfreetype.so.6()(64bit) so apparently gnomevfs is already there, probably could add the orbit thing as well; this fake-db is used with the user-install script so that could be used for testing the new dependencies at least for RPM (i'm asssuming DEBs have the same dependencies as RPMs).
Grief - you -really- don't want to be installing libbonobo2-0 - and I can tell you - I wrote/maintained it for years :-) it's dead and gone and good-riddance. If a gnome-vfs dep brings that monster back-to-life, we need to be switching to gio across the board in a speedy fashion :-)
(In reply to comment #18) > > the upstream RPMs at least only have dependencies on 2 or 3 libraries; > i can only speculate why that is but it's likely > that the reason is that the packages need to be installable on _every_ > weird linux distro and the package names and/or location of the files > on file system are different between different distros. And actually it doesn't really require anything else... So because they are universal, they don't have a long list of dependencies. > ... looking at the setup_native/scripts/fake-db.spec there is this list: That one is meant to install LibreOffice in a separate rpm-db, i.e. installing using rpm completely bypassing the system, so indeed this is the list of LibreOffice's dependencies as listed in the RPMs (assuming someone still runs that script that makes use of it/assuming it is maintained) > so apparently gnomevfs is already there, probably could add the orbit thing > as well; The dependencies of the actual packages are defined in setup_native/source/packinfo/packinfo_office.txt - for the gnome-integration package they are listed in the helper-script instsetoo_native/inc_openoffice/unix/find-requires-gnome.sh (kind of misleading name, as it doesn't "find" any requires, it just echoes a hardcoded list) the find-requires-gnome.sh together with find-requires-x11.sh contain all external dependencies defined in the packages. > this fake-db is used with the user-install script so that could be > used for testing the new dependencies at least for RPM (i'm asssuming DEBs > have the same dependencies as RPMs). Yes, debs have the same dependencies, but not sure whether deb has a concept of installing packages to a non-system package-database. But you won't be able to use the install-script to verify the dependencies, since vmiklos added nodeps to the commands, nullifying the effect and point of the fake-db.rpm (getting rid of --nodeps switch was the only reason to create that) - probably he didn't understand the concept/there was a different bug he was facing... http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8b5e1cb1e2a0b294b7c967a8e040e11d2da74f7 ############################## tl;dr if you want to add new dependencies (whether it makes sense or not from a technical POV is another question) add it to instsetoo_native/inc_openoffice/unix/find-requires-gnome.sh that is used by setup_native/source/packinfo/packinfo_office.txt if you want to check what external dependencies there are, you need to query the created rpms or look at the packinfo files, as the user-installscript bypasses the fake-db rpm due to the above commit.
I test on a new Virtaulbox with Ubuntu 12.04.1: LibreOffice Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) don't show this message during installation.
Is this still valid for LO 4.1.1.1? http://www.libreoffice.org/download/pre-releases/
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
so basically the bug is that Ubuntu has a libgnomevfs-2.so.0 which depends on obsolete bonobo libraries, which is clearly Ubuntu's bug