Summary: | app-office/libreoffice-4.3.5.2 - libreoffice: /usr/lib64/libreoffice/program/oosplash: error while loading shared libraries: libuno_sal.so.3: cannot open shared object file: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Massimo Burcheri <burcheri.massimo+bugs-gentoo> |
Component: | Current packages | Assignee: | Gentoo Office Team <office> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | 2kmm, martin |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://forums.gentoo.org/viewtopic-p-7711008.html | ||
Whiteboard: | not a regression in 4.3 | ||
Package list: | Runtime testing required: | --- |
Description
Massimo Burcheri
2015-01-14 07:23:58 UTC
What's the output of file /usr/lib64/libreoffice/ure/lib/libuno_sal.so.3 ? ... and what's the otuput of objdump -x /usr/lib64/libreoffice/program/oosplash | grep RUNPATH $ file /usr/lib64/libreoffice/ure/lib/libuno_sal.so.3 /usr/lib64/libreoffice/ure/lib/libuno_sal.so.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped $ objdump -x /usr/lib64/libreoffice/program/oosplash | grep RUNPATH RUNPATH $ORIGIN:$ORIGIN/../ure-link/lib (In reply to Massimo Burcheri from comment #3) > $ file /usr/lib64/libreoffice/ure/lib/libuno_sal.so.3 > /usr/lib64/libreoffice/ure/lib/libuno_sal.so.3: ELF 64-bit LSB shared > object, x86-64, version 1 (SYSV), dynamically linked, stripped > > $ objdump -x /usr/lib64/libreoffice/program/oosplash | grep RUNPATH > RUNPATH $ORIGIN:$ORIGIN/../ure-link/lib That looks both normal. :( For now this quick bugfix from Hotblack in the forums solves the issue, but eventually is not the cleanest way: # echo 'LDPATH="/usr/lib/libreoffice/ure/lib/:/usr/lib/libreoffice/program/"' >> /etc/env.d/99libreoffice_bug536558 # env-update Do you still have this problem with 4.4.x.y? I was hit by the same symptoms and investigated. I am using squashmount which offers to put libreoffice files in a squashfs allowing write access by overlayfs. But overlayfs alters /proc/self/exe which is used by libreoffice to find its libraries. See https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1007089 (In reply to Manuel Mommertz from comment #7) > But overlayfs alters /proc/self/exe which is used by libreoffice > to find its libraries. Interesting. However, I use libreoffice since quite a while with squashmount and overlay (previously overlayfs) and so far have never run into this problem. Could it be that it only occurs after emerging and before resquashing (i.e. when the binary does actually lie in the CHANGES directory instead of the compressed squashfs file)? (In reply to Martin Väth from comment #8) > Could it be that it only occurs after emerging and before resquashing (i.e. > when the binary does actually lie in the CHANGES directory instead of the > compressed squashfs file)? $ ls -a /usr/lib64/libreoffice.mount/changes/ . .. $ soffice /usr/lib64/libreoffice/program/oosplash: error while loading shared libraries: libuno_sal.so.3: cannot open shared object file: No such file or directory You can test this (modified version from launchpad): ( set -e; mkdir -p /mnt/test /tmp/usr /tmp/usr.work; mount none /mnt/test -t overlay -o lowerdir=/usr,upperdir=/tmp/usr,workdir=/tmp/usr.work; /mnt/test/bin/tail -f /dev/null& readlink /proc/$!/exe; kill $!; umount /mnt/test; rmdir /mnt/test /tmp/usr /tmp/usr.work/work /tmp/usr.work; ) If you see /bin/tail, your kernel has the bug, if you see /mnt/test/bin/tail your kernel is ok. As you say that you can run libreoffice from overlayfs, you should get /mnt/test/bin/tail, in which case the next question is: Why? Do you have an older kernel? Or maybe is the bug fixed in newer kernels? My kernel is: 4.0.5-gentoo I'm trying to run that test but it fails: # set -e; mkdir -p /mnt/test /tmp/usr /tmp/usr.work; mount none /mnt/test -t; overlay -o lowerdir=/usr,upperdir=/tmp/usr,workdir=/tmp/usr.work; /mnt/test/bin/tail -f /dev/null& readlink /proc/$!/exe; kill $!; umount; /mnt/test; rmdir /mnt/test /tmp/usr /tmp/usr.work/work /tmp/usr.work; mount: option requires an argument -- 't' (In reply to Massimo Burcheri from comment #10) > I'm trying to run that test but it fails: > > # set -e; mkdir -p /mnt/test /tmp/usr /tmp/usr.work; mount none /mnt/test > -t; overlay -o lowerdir=/usr,upperdir=/tmp/usr,workdir=/tmp/usr.work; > /mnt/test/bin/tail -f /dev/null& readlink /proc/$!/exe; kill $!; umount; > /mnt/test; rmdir /mnt/test /tmp/usr /tmp/usr.work/work /tmp/usr.work; > > mount: option requires an argument -- 't' Please put the complete command in one line. It should work then. Haven't heard anything about this for a long time. Please reopen if it still occurs. |