| View previous topic :: View next topic |
| Author |
Message |
Yminus
Apprentice
Joined: 06 Jan 2008
Posts: 184
|
 Posted: Sun May 27, 2012 5:39 pm Post subject: [SOLVED] grep: error while load. shared lib..s: libpcre.so.0 |
 |
|
After emerge -avuND world I followed the post install notice of dev-libs/libpcre-8.30-r2
| Quote: | >>> Messages generated by process 16054 on 2012-05-27 10:46:00 CEST for package dev-libs/libpcre-8.30-r2:
WARN: postinst
Old versions of installed libraries were detected on your system.
In order to avoid breaking packages that depend on these old libs,
the libraries are not being removed. You need to run revdep-rebuild
in order to remove these old dependencies. If you do not have this
helper program, simply emerge the 'gentoolkit' package.
# revdep-rebuild --library '/lib64/libpcre.so.0'
Once you've finished running revdep-rebuild, it should be safe to
delete the old libraries. Here is a copy & paste for the lazy:
# rm '/lib64/libpcre.so.0' |
revdep-rebuild reported nothing and I removed libpcre.so.0.
Now I can't compile anymore:
| Quote: |
checking how to run the C preprocessor... grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
x86_64-pc-linux-gnu-gcc -E
grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
checking for grep that handles long lines and -e... configure: error: no acceptable grep could be found in /usr/lib64/ccache/bin:/usr/lib64/distcc/bin:/usr/lib64/portage/bin/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3:/usr/lib64/subversion/bin:/opt/eagle-5.11.0/bin:/opt/cuda/bin:/usr/xpg4/bin
|
What can I do now?
Last edited by Yminus on Sat Jun 09, 2012 12:42 am; edited 1 time in total |
|
| Back to top |
|
 |
Yminus
Apprentice
Joined: 06 Jan 2008
Posts: 184
|
| Posted: Sun May 27, 2012 5:47 pm Post subject: |
|
|
I could recover by setting a symlink:
| Code: | | ln -s /lib64/libpcre.so.1 /lib64/libpcre.so.0 |
But now I still wonder why revdep-rebuild --library '/lib64/libpcre.so.0' did not rebuild grep. |
|
| Back to top |
|
|
lyallp
Veteran
Joined: 15 Jul 2004
Posts: 1555
Location: Adelaide/Australia
|
| Posted: Tue May 29, 2012 4:02 am Post subject: |
|
|
Don't forget to- re-emerge libpcre
- re-emerge grep
- revdep-rebuild -i
- delete the symlink you created
I did the same thing myself!
_________________
...Lyall |
|
| Back to top |
|
|
bobpaul
Tux's lil' helper
Joined: 09 Aug 2005
Posts: 148
|
| Posted: Fri Jun 08, 2012 6:19 pm Post subject: |
|
|
| Yminus wrote: | | But now I still wonder why revdep-rebuild --library '/lib64/libpcre.so.0' did not rebuild grep. |
If you look at your error, revdep-rebuild is using grep and failing. So that's why it didn't fix grep... it needs a working grep to figure out libpcre is broken... |
|
| Back to top |
|
|
Thistled
Guru
Joined: 06 Jan 2011
Posts: 572
Location: Scotland
|
| Posted: Sat Jun 09, 2012 12:28 am Post subject: |
|
|
So is this topic solved?
_________________
Whatever you do, do it properly! |
|
| Back to top |
|
|
lyallp
Veteran
Joined: 15 Jul 2004
Posts: 1555
Location: Adelaide/Australia
|
| Posted: Tue Jun 12, 2012 12:46 am Post subject: |
|
|
As far as I am concerned it is.
_________________
...Lyall |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Jun 12, 2012 1:11 am Post subject: |
|
|
| bobpaul wrote: | | If you look at your error, revdep-rebuild is using grep and failing. So that's why it didn't fix grep... it needs a working grep to figure out libpcre is broken... |
Well, no, grep should have been rebuilt (against libpcre.so.1) prior to the removal of libpcre.so.0 ... and so should not have needed libpcre.so.0 subsequent to the revdep-rebuild.
I did this upgrade probably the same time as the OP, or at least within a day or so of its release, and didn't have any issues. Also, the 'pcre' use flag is likewise set on sys-apps/grep so I'm somewhat puzzled why this might have happened. I was careful at the time to check everything was working and compared 'equery depends libpcre' against revdep-rebuilds list for any packages on which the pcre useflag was enabled, but everything was listed, and then rebuilt, as expected.
I could only speculate on possible reasons, perhaps the build died for some other reason, I have -nls as a global useflag, nls being the only other useflag for sys-apps/grep, but if "nls" was the cause then I think there would be many more reports of this issue as its the default. AFAIK there is no verfication of this, or did others have a similar problem?
Anyhow ... I'm always careful when using '--deep', but I've always found revdep-rebuild to work flawlessly, so if at all possible it'd be good to get to the root of this.
best ... khay |
|
| Back to top |
|
|
lyallp
Veteran
Joined: 15 Jul 2004
Posts: 1555
Location: Adelaide/Australia
|
| Posted: Tue Jun 12, 2012 8:42 am Post subject: |
|
|
My problem was I deleted the .so prior to doing the revdep-rebuild (thinking I had already done it).
Big mistake, won't do that again!
_________________
...Lyall |
|
| Back to top |
|
|
Yminus
Apprentice
Joined: 06 Jan 2008
Posts: 184
|
| Posted: Tue Jun 12, 2012 8:33 pm Post subject: |
|
|
| khayyam wrote: | | grep should have been rebuilt (against libpcre.so.1) prior to the removal of libpcre.so.0 |
That's what I expected.
| khayyam wrote: | | I could only speculate on possible reasons, perhaps the build died for some other reason |
There was no built - revdep-rebuild did not report anything.
| khayyam wrote: | | I have -nls as a global useflag, nls being the only other useflag for sys-apps/grep, but if "nls" was the cause then I think there would be many more reports of this issue as its the default. |
I have nls set.
| khayyam wrote: | | Anyhow ... I'm always careful when using '--deep' |
I frequently do:
| Code: | layman -S && eix-sync && emerge -avuND world
emerge -avc
revdep-rebuild -- -av |
Sometimes emerge -avc requires | Code: | | emerge --update --newuse --deep --with-bdeps=y @world |
I thought this is the recommended procedure to keep the system up to date?
| khayyam wrote: | | I ... compared 'equery depends libpcre' against revdep-rebuilds list for any packages on which the pcre useflag was enabled, but everything was listed, and then rebuilt, as expected. |
I checked it today and according to /var/log/emerge.log all of them have been rebuild after my symlink workaround.
So I have no explanation and I cannot reproduce the problem. Maybe I messed it without noticing at first and as long there is no verification of this problem I believe this is an adequate working hypothesis. So for me this issue is solved. |
|
| Back to top |
|
|
aharel
n00b
Joined: 16 Nov 2011
Posts: 36
|
| Posted: Wed Oct 17, 2012 8:37 am Post subject: Started the same - got worst |
|
|
| Quote: | I think there would be many more reports of this issue as its the default. AFAIK there is no verfication of this, or did others have a similar problem?
|
I did last night.
The post install notice of dev-libs/libpcre-8.30-r2 had fancier command line cut and paste, which first runs revdep-build and then rmoves libpcre.so.0. But I thought (no log?) that devdep-build did nothing but complain. And after several failed emerges of libpcre (after one emerge of a library that depends on in) I realized there is no libpcre in /lib64. There is one in /lib32, but I don't see how this helps.
So emerge is broken, as is configurate in the pcre package.
Any ideas how to revive my gentoo? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Oct 17, 2012 12:40 pm Post subject: Re: Started the same - got worst |
|
|
| aharel wrote: | | Any ideas how to revive my gentoo? |
Funny, I answered a very similar question just recently (see the post immediately after it as well.) |
|
| Back to top |
|
|
aharel
n00b
Joined: 16 Nov 2011
Posts: 36
|
| Posted: Wed Oct 17, 2012 1:34 pm Post subject: Thanks and discussion of post install instructions |
|
|
Thanks Steve.
I was going to update that I resolved it using a different thread, and then saw your answer, which was essentially the same 
So you did good, and I was too slow 
Back to the source of this mess:
Being a complete n00b (and currently reinstalling KDE&QT as part of the price) I don't want to post a bug report yet without getting some feedback from more experiences users: does it really make sense to have "rm" of a .so file that's needed for emerge (here, via configurate via grep) in the post install instructions? Especially without some check that a newer (or at least different) version exists?
Perhaps the package maintainer assumed that any revedep-build failures would prevent the "&&" clause from running. That was not the case for me, and anyway, that's not quite the right check. I think.... |
|
| Back to top |
|
|
|
Portage & Programming
