re[SOLVED] boost-libs upgrade breaks ncmpcpp?

matchew · 2016-09-12 14:07:16

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)

mpan · 2016-09-12 14:29:37

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.

matchew · 2016-09-12 14:39:17

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)

WorMzy · 2016-09-12 15:01:45

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.

mpan · 2016-09-12 15:43:20

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.

eschwartz · 2016-09-12 18:16:39

Responsible AUR maintainers should be bumping the pkgrel when this happens...

WorMzy · 2016-09-12 19:41:13

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.

matchew · 2016-09-12 19:41:39

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.

eschwartz · 2016-09-12 19:54:53

WorMzy wrote:

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.

mpan · 2016-09-12 23:09:37

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).

eschwartz · 2016-09-13 18:18:03

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".

Arch Linux

#1 2016-09-12 14:07:16

re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#2 2016-09-12 14:29:37

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#3 2016-09-12 14:39:17

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#4 2016-09-12 15:01:45

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#5 2016-09-12 15:43:20

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#6 2016-09-12 18:16:39

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#7 2016-09-12 19:41:13

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#8 2016-09-12 19:41:39

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#9 2016-09-12 19:54:53

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#10 2016-09-12 23:09:37

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

#11 2016-09-13 18:18:03

Re: re[SOLVED] boost-libs upgrade breaks ncmpcpp?

Board footer