You are not logged in.
I am not sure if I am understanding the issue correctly, nor if this is a package upgrade issue per say.
But this is what I know
1. boost-libs updated on 10 sept 2016.
2. I ran
# pacman -Syu
this morning
3.and now
ncmpcpp
is throwing the error
ncmpcpp: error while loading shared libraries: libboost_filesystem.so.1.60.0: cannot open shared object file: No such file or directory
4. strace output
$ strace ncmpcpp
execve("/usr/bin/ncmpcpp", ["ncmpcpp"], [/* 42 vars */]) = 0
brk(NULL) = 0x24d6000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=145679, ...}) = 0
mmap(NULL, 145679, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7abfdf1000
close(3) = 0
open("/usr/lib/tls/x86_64/libboost_filesystem.so.1.60.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/tls/x86_64", 0x7fff1246c240) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libboost_filesystem.so.1.60.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/tls", 0x7fff1246c240) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libboost_filesystem.so.1.60.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64", 0x7fff1246c240) = -1 ENOENT (No such file or directory)
open("/usr/lib/libboost_filesystem.so.1.60.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=139264, ...}) = 0
writev(2, [{iov_base="ncmpcpp", iov_len=7}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libboost_filesystem.so.1.60.0", iov_len=29}, {iov_base=": ", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30}, {iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25}, {iov_base="\n", iov_len=1}], 10ncmpcpp: error while loading shared libraries: libboost_filesystem.so.1.60.0: cannot open shared object file: No such file or directory
) = 136
exit_group(127) = ?
+++ exited with 127 +++
5.
$ ls -l /usr/lib/libboost_filesystem.so*
lrwxrwxrwx 1 root root 29 Aug 17 16:58 /usr/lib/libboost_filesystem.so -> libboost_filesystem.so.1.61.0
-rwxr-xr-x 1 root root 101584 Aug 17 17:01 /usr/lib/libboost_filesystem.so.1.61.0
I feel like this will result on a simple fix on my end, but little sleep and lack of coffee has left the contemplation sluggish.
EDIT: currently rebuilding AUR package ncmpcpp-git. Will see if this resolves issue.
EDIT #2: Yep, rebuild the AUR package ncmpcpp-git did the trick.
Last edited by matchew (2016-09-12 14:14:33)
Offline
No, it’s not solved — the situation should not occur. You have a partial update probably, or have some non-repo package that breaks things. Rebuild shouldn’t be needed: ncmpcpp works without problems.
Run:
LANG=C pacman -Qo $(ldd /usr/bin/ncmpcpp | while read target sep file garbage; do
if [[ '=>' == "$sep" ]]; then
echo "$file"
fi
done) | while read file sepIs sepOwned sepBy pkg ver; do
echo "$pkg $ver"
done | sort | uniq
You should have received:
boost-libs 1.61.0-2
curl 7.50.2-1
e2fsprogs 1.43.3-1
fftw 3.3.5-1
gcc-libs 6.2.1-1
glibc 2.24-2
icu 57.1-1
keyutils 1.5.9-1
krb5 1.13.4-1
libidn 1.33-1
libmpdclient 2.10-1
libssh2 1.7.0-2
ncurses 6.0-4
openssl 1.0.2.h-1
readline 6.3.008-4
taglib 1.11-1
zlib 1.2.8-4
ncmpcpp should be 0.7.5-2.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
boost-libs 1.61.0-2
curl 7.50.2-1
e2fsprogs 1.43.3-1
fftw 3.3.5-1
gcc-libs 6.2.1-1
glibc 2.24-2
icu 57.1-1
keyutils 1.5.9-1
krb5 1.13.4-1
libidn 1.33-1
libmpdclient 2.10-1
libssh2 1.7.0-2
ncurses 6.0-4
openssl 1.0.2.h-1
readline 6.3.008-4
taglib 1.11-1
zlib 1.2.8-4
could it be related to the fact that I am using AUR ncmpcpp-git and not ncmpcpp from community?
$ ncmpcpp -v
ncmpcpp 0.8_dev
optional screens compiled-in:
- tag editor
- tiny tag editor
- artist info
- outputs
- visualizer
- clock
encoding detection: enabled
built with support for: curl fftw ncurses taglib unicode
Last edited by matchew (2016-09-12 14:41:02)
Offline
Yes. I'm not sure mpan saw that you are using the -git package. As always, any packages you install from the AUR are your responsibility to rebuild after soname bumps.
Mod note: Moving to AUR Issues.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I have noticed the “-git” suffix, but I thought OP is trying to fix the original issue by trying out the AUR package. Confirmed by the fact, that the thread was in a category related to official repos…
Since it’s about AUR package, I have no further comments.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Responsible AUR maintainers should be bumping the pkgrel when this happens...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
As the maintainer of several -git packages, I respectfully disagree. AUR -git packages should only be pkgrel bumped when the PKGBUILD changes, pkgrel bumping for soname bumps only makes sense for precompiled packages.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Yeah, I posted in the wrong sub forum. Thank you for moving. Sorry for any confusion. Hopefully this may help someone else in the future.
Thanks.
Offline
As the maintainer of several -git packages, I respectfully disagree. AUR -git packages should only be pkgrel bumped when the PKGBUILD changes, pkgrel bumping for soname bumps only makes sense for precompiled packages.
Surely the pkgrel should be bumped whenever it is important to rebuild an existing version of a package... for whatever reason...
Granted that it is the user's responsibility to manage AUR packages, but I really don't see what is objectionable about flagging it as necessary for manual rebuild.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I believe we’re drifting towards an offtopic, so maybe a new thread for this, if you wish to continue the discussion.
If this would be about an AUR package that is updated only when the upstream releases a new version, it is sane to expect from the maintainer to track changes in deps and bump pkgrel. Here we’re dealing with a VCS-based package. What you’re asking for would require from a maintainer continuous building and testing on each new upstream commit — this would be the only way to ever detect something is wrong. The other option is to blindly increment pkgrel on each commit — less burdersome for the maintainer, much more inconvenient for the users (unconditional daily rebuilds) and AUR itself (millions of commits that actually do nothing).
And even this would not prevent breaks. Hence I believe the current policy of incrementing pkgrel of VCS-based packages only when a problem is detected, is the better one. If someone makes a decision to use a VCS version, it should be assumed they’re intending to be as close to the head as possible (implies rebuilding things regularly on their own) and wish to participate in the issues-finding process (implies being prepared to dealing with broken builds).
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Right -- I as a *-git package maintainer also, only increment VCS pkrels "when a problem is detected"... like, for example, when there is a sover bump in the main repos...
Which would solve the problem of this thread. Because users would find it a lot easier to keep track of when AUR packages need to be rebuilt, vs.
doing a full ldd check on every binary executable on their system after every update, or
check every upgraded file in /usr/lib (despite no way of doing so, without e.g. hooks) to eyeball and see which ones got a sover bump, or
track the non-git version of everything that has a non-git alternative in the main repos, using e.g. asp, and check for warning signs like "____ rebuild" in the commit logs.
"for whatever reason" was "including sover bumps" as opposed to just "because of this critical patch" or "because of this new dependency" or "because of this new build()/package() procedure".
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline