You are not logged in.
I got many lines of "libpcre.so.0: cannot open shared object file: No such file or directory" when I was performing "pacman -Syu".
http://pastebin.mozilla.org/1488774
Which package was actually requiring it? Firefox? Is my libpcre.so.0 not locating in the right directory? My question sounds so nut but I don't know what is the cause. Please... give me some advice. Thank you very much to anyone to would help!
Offline
From the pacman ArchWiki article:
To list all the packages needed by a package, use whoneeds from pkgtools:
whoneeds pcre
Please mark this thread [solved] if this answers your question.
Offline
From that output it looks like the problem was with the filesystem packages and all the errors seem to be with grep.
First you should check what version of pcre and grep you have installed, the current pcre is 8.30-1 and grep is 2.10-3. If you have both of those installed it might have been a problem with things being inconsistent while pacman was running. To be safe it might be a good idea to reinstall filesystem, or any other packages that might have also given errors if there's more errors you didn't show.
If you have a different version you should try changing mirrors to get the right packages.
Offline
Vote for this bug. After "libpcre.so" changed from "0" to "1", programs that use it must be recompiled. I already discovered programs that were not recompiled ("mcedit", "syslog-ng", "update-desktop-database", "gtk-update-icon-cache"), and there are probably more ones to be discovered.
Alternatively, downgrade "pcre" to "8.21-1" and downgrade other programs (e.g. "grep").
Last edited by beroal (2012-02-20 20:44:46)
we are not condemned to write ugly code
Offline
Vote for this bug. After "libpcre.so" changed from "0" to "1", programs that use it must be recompiled. I already discovered programs that were not recompiled ("mcedit", "syslog-ng"), and there are probably more ones to be discovered.
Alternatively, downgrade "pcre" to "8.21-1" and downgrade other programs (e.g. "grep").
everything from our repositories have been recompiled against new pcre. I suggest to fully update your system and check for unsupported packages you may have installed(pacman -Qm) and recompile.
Give what you have. To someone, it may be better than you dare to think.
Offline
Without seeing the rest of the upgrade, it's not really clear what the state of your machine is, but it seems likely given the size of the upgrade that it went something like...
- upgrade libpcre, grep is now broken because it still links against the old soname
- upgrade filesystem -- relies on grep in the install scriptlet, so errors galore
- upgrade grep, order is restored
In the end, it's nothing really to worry about. We didn't make any changes to the install scriptlet for filesystem, so you're missing out on a "refresh". If you want to be paranoid, just reinstall core/filesystem.
Offline
everything from our repositories have been recompiled against new pcre. I suggest to fully update your system and check for unsupported packages you may have installed(pacman -Qm) and recompile.
I updated my OS. E.g., the last version of "gtk-update-icon-cache" is "2.24.10-1" and it does require "libpcre.so.0".
we are not condemned to write ugly code
Offline
grep is now broken because it still links against the old soname
Actually, "grep-2.10-3" links against the new soname. Do we use the same distribution?
Last edited by beroal (2012-02-20 20:51:34)
we are not condemned to write ugly code
Offline
falconindy wrote:grep is now broken because it still links against the old soname
Actually, "grep-2.10-3" links against the new soname. Do we use the same distribution?
Not sure, do we?. I use Arch Linux. I also have a pretty good understanding of package managers, dependencies, and dynamic linking.
Offline
Andrea Scarpino (BaSh) wrote:
No, it doesn't:
$ readelf -d /usr/bin/mcedit | grep libpcre.so
$
No, it does. "mcedit-4.8.1-1" does not start with "pcre-8.30-1" and starts with "pcre-8.21-1". And with "pcre-8.30-1" it specifically requires "libpcre.so.0".
Last edited by beroal (2012-02-20 21:53:29)
we are not condemned to write ugly code
Offline
From the original post:
( 10/107) upgrading filesystem [######################] 100%
This was a large upgrade. Presumably, grep and libpcre were both upgraded as part of this. When pacman calculates the dependency graph, it considers ordering of installation to prevent things like this. However, if you look at the filesystem package's depends:
$ pacman -Si filesystem | grep '^Depends'
Depends On : iana-etc bash coreutils
You'll notice that grep is not a requirement. Perhaps the fault of the packager, but it's not really relevant. Let's squeeze down the transaction and substitute our own reality (as you seem to enjoy with taking my words out of context).
'pacman -Syu' pulls in exactly three packages: pcre, filesystem, and grep. pacman writes draws out its dependency graph and decides that the packages, as I've listed them, is a reasonable install order (because hey, it doesn't realize that filesystem depends on a working grep). So here we go again:
1) pacman removes pcre-8.21, installs pcre-8.30.
At this point. grep is broken, because 2.10-2 is still installed. It links against libpcre.so.0, which was just removed.
2) pacman removes filesystem 2011.12, installs filesystem 2012.2. What happens now when grep is executed? Oh right, it explodes like the OP showed.
3) pacman removes grep 2.10-2 and installs grep 2.10-3. Only now is grep working again because the new package.
Hey look, one of my older VMs even shows this!! What're the odds!?!?!
http://paste.xinu.at/Oxe/
Look at line 24 (pcre upgraded)
Followed by lines 43-110 (filesystem upgraded)
And then line 116 (grep upgraded)
Offline
beroal wrote:Vote for this bug. After "libpcre.so" changed from "0" to "1", programs that use it must be recompiled. I already discovered programs that were not recompiled ("mcedit", "syslog-ng"), and there are probably more ones to be discovered.
Alternatively, downgrade "pcre" to "8.21-1" and downgrade other programs (e.g. "grep").
everything from our repositories have been recompiled against new pcre. I suggest to fully update your system and check for unsupported packages you may have installed(pacman -Qm) and recompile.
Another temporary work-around is to symlink /usr/lib/libpcre.so.0 to libpcre.so.1 At least I got mysql-workbench to load...
Offline
wonder wrote:beroal wrote:Vote for this bug. After "libpcre.so" changed from "0" to "1", programs that use it must be recompiled. I already discovered programs that were not recompiled ("mcedit", "syslog-ng"), and there are probably more ones to be discovered.
Alternatively, downgrade "pcre" to "8.21-1" and downgrade other programs (e.g. "grep").
everything from our repositories have been recompiled against new pcre. I suggest to fully update your system and check for unsupported packages you may have installed(pacman -Qm) and recompile.
Another temporary work-around is to symlink /usr/lib/libpcre.so.0 to libpcre.so.1 At least I got mysql-workbench to load...
Do. Not. Do. This.
Offline
Tried to install pkg from aur but it wouldn't compile (yes, after full sys upgrade) so its either this, wait for aur package to get patched or compile from source...which is discouraged.
Offline
Tried to install pkg from aur but it wouldn't compile (yes, after full sys upgrade) so its either this, wait for aur package to get patched or compile from source...which is discouraged.
First, what package?
we are not condemned to write ugly code
Offline
@mpz
mcedit is in the repos and it should just work.
Offline
I have met this issue before.
and solved it by:
1. upgrade pcre
2. reboot
3. upgrade rest packages and/or re-install those showed error messages.
hope this helps.
Offline
mpz wrote:Tried to install pkg from aur but it wouldn't compile (yes, after full sys upgrade) so its either this, wait for aur package to get patched or compile from source...which is discouraged.
First, what package?
My first post, mysql-workbench.
Offline
Tried to install pkg from aur but it wouldn't compile (yes, after full sys upgrade) so its either this, wait for aur package to get patched or compile from source...which is discouraged.
I just built it:
==> Finished making: mysql-workbench 1:5.2.37-8 (Tue Feb 21 08:10:36 UTC 2012)
Offline
mysql-workbench.
IMHO it's better to go to the package discussion page.
we are not condemned to write ugly code
Offline
Okay, it was a custom version of "glib2" requiring "libpcre.so.0". The problematic programs require "glib2", not "libpcre".
we are not condemned to write ugly code
Offline