You are not logged in.
Can I mark this UN[SOLVED] ? I'm having the exact same issue, having upgraded everything (right now) and did a reboot. This looks fishy to me:
~ » journalctl -r -n 200 --no-pager | grep xfdesktop | tail -n 1
Mar 23 10:27:45 apex slim[8763]: xfdesktop: error while loading shared libraries: libxfce4util.so.6: cannot open shared object file: No such file or directory
~ » pacman -Qs | grep xfdesktop
local/xfdesktop 4.12.1-1 (xfce4)
~ » ldd `which xfdesktop` | grep libxfce
libxfce4ui-1.so.0 => /usr/lib/libxfce4ui-1.so.0 (0x00007ff26e6ac000)
libxfce4util.so.7 => /usr/lib/libxfce4util.so.7 (0x00007ff26de04000)
libxfce4util.so.6 => not found
BTW xfce4-panel is having the same issue.
-- mod note: split from existing thread and moved to NC. Trilby --
Last edited by Trilby (2015-03-23 11:12:49)
Offline
What packages from AUR or unofficial repos do you have installed?
Offline
@karol Here's a complete list from pacman -Qm http://ix.io/h2Y
Offline
Did you rebuild all the xfce stuff?
Offline
Nope, it's all from Arch's repos. I'm ready to submit a bug, last chance to point at my error.
Offline
I don't understand what you mean. 'pacman -Qm' prints packages that are not in the repos. Mayeb they once were, but are not, see for yourself.
Do you know how AUR works?
Offline
I know how AUR works, I do have some packages from AUR, I use aura to retrieve, build and install them. AFAIK pacman -Qm lists those packages. Can please be more verbose? I have no idea where are you heading with those questions and it makes less willing to answer them. xfdesktop and xfce4-panel (at least) are broken, and they are in Arch's extra repo, they're not from AUR. Here, look at this, I got the URL of the package from https://www.archlinux.org/packages/extr … xfdesktop/ (Download from mirror link)
~/Downloads » curl -O http://mirror.de.leaseweb.net/archlinux/extra/os/x86_64/xfdesktop-4.12.1-1-x86_64.pkg.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 724k 100 724k 0 0 2064k 0 --:--:-- --:--:-- --:--:-- 2064k
~/Downloads » tar xf xfdesktop-4.12.1-1-x86_64.pkg.tar.xz
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
~/Downloads » ldd usr/bin/xfdesktop | grep libxfce
libxfce4ui-1.so.0 => /usr/lib/libxfce4ui-1.so.0 (0x00007f81f4893000)
libxfce4util.so.7 => /usr/lib/libxfce4util.so.7 (0x00007f81f3feb000)
libxfce4util.so.6 => not found
Offline
xfdesktop and xfce4-panel (at least) are broken, and they are in Arch's extra repo, they're not from AUR.
No they're not. Your AUR packages are broken. You're replacing some official packages with unofficial versions from AUR (I see at least exo-git) and rebuilding them for new versions of libraries is your job.
Offline
I can't replicate that - when I run those exact same commands to download from the same mirror, extract, and ldd, I do not get a listing for line libxfce4uitl.so.6. The binary on that mirror is not linked to that library. It seems the linker/loader on your system might be adding it. This is likely due - as Karol has said - to one of your AUR packages that needs to be rebuilt. That was the solution in the original thread for the exact same error. Why are you so resistant to considering that as a possibility?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
@Trilby In that case, I apologize, and admit that I don't know how ldd works. Does that mean, eg. for xfdesktop binary, it depends on some library, that I have from AUR, and have not been rebuilt? Any suggestions on how to find out which one it is without re-building everything I have from AUR?
Offline
@arojas: yes it was exo-git. I thought that ldd is printing only direct dependencies. So again, I apologize. Would anyone be so kind and explain to me why ldd was printing that dep due to outdated exo-git?
Offline
Perhaps arojas, or someone else can provide a better explanation as I don't know the details. But I do know that the linker/loader does cache libraries. If you have something running that requires the old version of the lib, the path to that old version may be cached, so on the next look up (triggered by some other program: xfdesktop in this case) the cached version might match. This is a bit of speculation on the mechanism though. I don't know the inner workings of the linker/loader.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Would anyone be so kind and explain to me why ldd was printing that dep due to outdated exo-git?
ldd lists linked libraries recursively. Use readelf -d to list direct dependencies only.
Offline