FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-06-2011, 09:43 AM
Dale
 
Default checking whether the C compiler works... no Oooops !!

Alan McKinnon wrote:

Apparently, though unproven, at 11:15 on Friday 06 May 2011, justin did opine
thusly:



On 06/05/11 11:08, Dale wrote:


That shed any light?

Dale

:-) :-)


Yes it does

/usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
libraries: libmpfr.so.1: cannot open shared object file: No such file or
directory

you upgraded your mpfr. Now you have to rebuild your gcc as well.


That's gonna be fun.

He doesn't have a working gcc to use to rebuild gcc.




It would be but having a older binary of mpfr saved my butt. I knew I
was keeping those around for some reason. ;-)


Going to keep a eye on the next mpfr update tho. o_O

Dale

:-) :-)
 
Old 05-06-2011, 10:18 AM
Andrea Conti
 
Default checking whether the C compiler works... no Oooops !!

> /usr/libexec/gcc/i686-pc-linux-gnu/4.4.4/cc1: error while loading shared
> libraries: libmpfr.so.1: cannot open shared object file
>
> Meaning, run revdep-rebuild

Yeah, right. So revdep-rebuild does its thing, finds out that gcc is
broken and tries to rebuild it with the broken gcc

In this case the only way out involves backups or binary packages, or
doing a binary build of the old mpfr version on another machine with
CFLAGS compatible to those in use on the target.

What's strange however, is that AFAIK in order to avoid this kind of
breakage system ebuilds such as mpfr never delete old library versions;
they just print a warning saying that the old library has been kept
around and should be manually deleted after running revdep-rebuild.

On all my sytems the transition to dev-libs/mpfr-3 was handled this way;
note that I am still using portage 2.1, so this has nothing to do with
the "preserve" feature in 2.2.

andrea
 
Old 05-06-2011, 10:23 AM
Albert Hopkins
 
Default checking whether the C compiler works... no Oooops !!

On Fri, 2011-05-06 at 12:18 +0200, Andrea Conti wrote:
> AFAIK in order to avoid this kind of
> breakage system ebuilds such as mpfr never delete old library
> versions;
> they just print a warning saying that the old library has been kept
> around and should be manually deleted after running revdep-rebuild.
>
> On all my sytems the transition to dev-libs/mpfr-3 was handled this
> way

Perhaps the OP performed the latter step before performing the former?
 
Old 05-06-2011, 03:06 PM
walt
 
Default checking whether the C compiler works... no Oooops !!

On 05/06/2011 12:45 AM, Dale wrote:

> checking for i686-pc-linux-gnu-gcc... gcc
> checking whether the C compiler works... no

I know you have it fixed now, but just thought I'd mention that
you will see the same error when compiling something in a directory
where you don't have write privileges.

I doubt you'll ever see it when using emerge because portage warns
you when you try to emerge something as an ordinary user, but I run
into it occasionally when I unpack a tarball as root and then try
to compile it as me.
 
Old 05-06-2011, 11:20 PM
Dale
 
Default checking whether the C compiler works... no Oooops !!

Dale wrote:


On the list of things to do. Running python-updater now will run that
next.


Thanks.

Dale

:-) :-)



Well, this ain't good. Neither python-updater nor revdep-rebuild can
complete. Either it is a missing package or some other error. Am I to
the point where I have to reinstall?


I'm going to try that script from many ages ago that rebuilds after a
gcc upgrade. Maybe it will do something different.


Dale

:-) :-)

P. S. One would think a Gentoo system could sit idle for a couple
months without this sort of mess. :/ I could see this after many
months or a year or longer but not a couple months.
 
Old 05-06-2011, 11:23 PM
Dale
 
Default checking whether the C compiler works... no Oooops !!

Albert Hopkins wrote:

On Fri, 2011-05-06 at 12:18 +0200, Andrea Conti wrote:


AFAIK in order to avoid this kind of
breakage system ebuilds such as mpfr never delete old library
versions;
they just print a warning saying that the old library has been kept
around and should be manually deleted after running revdep-rebuild.

On all my sytems the transition to dev-libs/mpfr-3 was handled this
way


Perhaps the OP performed the latter step before performing the former?




I generally do my updates, run revdep-rebuild, then --depclean then
revdep-rebuild again, in case --depclean broke something. So far, that
has always resulted in a clean system. I'm not sure what happened this
time tho. I'm pretty sure I left it sane tho. It certainly isn't sane
now tho. Neither am I right now. lol


Dale

:-) :-)
 
Old 05-06-2011, 11:40 PM
Alex Schuster
 
Default checking whether the C compiler works... no Oooops !!

Dale writes:

> Dale wrote:
> > On the list of things to do. Running python-updater now will run that
> > next.

> Well, this ain't good. Neither python-updater nor revdep-rebuild can
> complete. Either it is a missing package or some other error. Am I to
> the point where I have to reinstall?

Add the --keep-going option for emerge. Python-updater and revdep-rebuild
then will continue after an error, and give you a list of packages that
failed at the end. You can deal with them later.
I also suggest using -j (and --load-average=XX in EMERGE_DEFAULT_OPTS), this
gives a nice overview of what's done and what not.

You need to put '--' before these options for emerge so revdep-
rebuild/python-updater will not take them as their own arguments.

Wonko
 
Old 05-06-2011, 11:57 PM
Dale
 
Default checking whether the C compiler works... no Oooops !!

Alex Schuster wrote:

Dale writes:



Dale wrote:


On the list of things to do. Running python-updater now will run that
next.



Well, this ain't good. Neither python-updater nor revdep-rebuild can
complete. Either it is a missing package or some other error. Am I to
the point where I have to reinstall?


Add the --keep-going option for emerge. Python-updater and revdep-rebuild
then will continue after an error, and give you a list of packages that
failed at the end. You can deal with them later.
I also suggest using -j (and --load-average=XX in EMERGE_DEFAULT_OPTS), this
gives a nice overview of what's done and what not.

You need to put '--' before these options for emerge so revdep-
rebuild/python-updater will not take them as their own arguments.

Wonko





I already have --keep-going in make.conf. Good thought tho. Thing is,
it errors before it even starts. Complains about blockers and the
packages aren't even installed to block anything. Mostly KDE stuff too.


I'm running the script and will see what it does. Maybe it will fix it
since this is its purpose. <Dale crosses fingers> If that doesn't work,
I may go back to a bare system and try to start from there. I can then
emerge -k and see how long that takes.


Dale

:-) :-)
 
Old 05-07-2011, 04:00 AM
Grant Edwards
 
Default checking whether the C compiler works... no Oooops !!

On 2011-05-06, Dale <rdalek1967@gmail.com> wrote:

> P. S. One would think a Gentoo system could sit idle for a couple
> months without this sort of mess.

It depends on which "couple of months" you happen to pick.

Most of the time "a couple months" is OK. Once in a while there will
be several major updates for different packages in a short span and
for certain configurations if you don't do them incrementally stuff
breaks rather badly without some rather detailed shepherding from the
user along the way.

Still, it's nothing like the major upgrade disasters and RPM
dependency hell that I so vividly remember from my RedHat and Mandrake
days.

I specifically remember trying to upgrade from RedHat 6.x to 7.0. It
was a complete disaster. It turned out that even a clean install of
RH 7.0 was almost unusable, and the "7" series was really ready for
prime time until about 7.3. That was when I gave up on RedHat -- and
I had been using RedHat since before they used version numbers (I
think I started with the "Mother's Day" release).

Mandrake seemd a little better, but it still had the same basic
problem: any time you wanted a package that wasn't on the base install
CD, the only viable choice was to build it from sources, because every
binary RPM that you could find always required different library
versions that what you hand installed. When you tried to build from
source, you found out you didn't have have the "devel" versions of the
right libararies. If you tried to update libraries it would start a
chain-reaction of dependancy problems that didn't end until you were
standing there with a smoking gun picking bits of drive platter out of
your hair.
 
Old 05-07-2011, 07:45 AM
Andrea Conti
 
Default checking whether the C compiler works... no Oooops !!

> Well, this ain't good. Neither python-updater nor revdep-rebuild can
> complete. Either it is a missing package or some other error. Am I to
> the point where I have to reinstall?

If you can't sort out the mess manually, try emerge -e system, then
emerge -e world. You can also save some time by substituting the above
with emerge -eb system followed by emerge -ek world (this will skip a
second build of the system set by using binary packages from the first
build. If you have FEATURES=buildpkg, you should delete the contents of
your binary package directory before starting).

Although, depending on your hardware and on the contents of your wold
file, just reinstalling the whole thing could be faster.

andrea
 

Thread Tools




All times are GMT. The time now is 11:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org