Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
Dale wrote: Here is a update. I been going back and forth with python-updater and revdep-rebuild and it just never seems to finish cleanly. I think it reached a stalemate. So, I'm doing a emerge -e world which will also upgrade KDE. Maybe this will get it going again. Dale :-) :-) Last update. After doing a emerge -e world, everything comes up clean. Python-updater and revdep-rebuild is now happy. So, next time I don't update a rig for a while, I'm just going to emerge everything and be done with it. May use that nifty little script next time tho. It seems to do a better job for this sort of thing. Thanks to all. Dale :-) :-)
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
Dale wrote: 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 :-) :-) Here is a update. I been going back and forth with python-updater and revdep-rebuild and it just never seems to finish cleanly. I think it reached a stalemate. So, I'm doing a emerge -e world which will also upgrade KDE. Maybe this will get it going again. Dale :-) :-)
Re: [gentoo-user] Re: 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
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
Nikos Chantziaras wrote:
No, that's not it. It's this:
!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log
Hmmm. Thought it was the same. Here goes but it is lengthy:
root@smoker / # cat
/var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by sandbox configure 2.4, which was
generated by GNU Autoconf 2.65. Invocation command line was
$ ../sandbox-2.4//configure --prefix=/usr --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib
## - ##
## Platform. ##
## - ##
hostname = smoker
uname -m = i686
uname -r = 2.6.36-gentoo-r5
uname -s = Linux
uname -v = #1 PREEMPT Mon Dec 27 05:46:37 CST 2010
/usr/bin/uname -p = AMD Athlon(tm) XP 2500+
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/lib/portage/bin/ebuild-helpers
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /opt/bin
PATH: /usr/i686-pc-linux-gnu/gcc-bin/4.4.4
## --- ##
## Core tests. ##
## --- ##
configure:2399: checking for a BSD-compatible install
configure:2467: result: /usr/bin/install -c
configure:2478: checking whether build environment is sane
configure:2528: result: yes
configure:2669: checking for a thread-safe mkdir -p
configure:2708: result: /bin/mkdir -p
configure:2721: checking for gawk
configure:2737: found /usr/bin/gawk
configure:2748: result: gawk
configure:2759: checking whether make sets $(MAKE)
configure:2781: result: yes
configure:2896: checking environment state
PORTAGE_FEATURES=assume-digests binpkg-logs buildpkg distlocks
fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned
sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch
PVR=2.4
FETCHCOMMAND_SSH=bash -c x=\${2#ssh://} ; host=\${x%%/*} ;
port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]]
port=22 ; exec rsync --rsh=\ssh -p\${port}\ -avP
\\${host}:/\${x#*/}\ \\$1\ rsync ${DISTDIR}/${FILE} ${URI}
KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc
x86 ~sparc-fbsd -x86-fbsd
A=sandbox-2.4.tar.xz
LDFLAGS=-Wl,-O1 -Wl,--as-needed
NUT_DRIVERS=cyberpower
SANE_BACKENDS=hp
ALSA_CARDS=
XTABLES_ADDONS=quota2 psd pknock lscan length2 ipv4options ipset ipp2p
iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark
dhcpmac delude chaos account
D=/var/tmp/portage/sys-apps/sandbox-2.4/image/
PORTAGE_IPC_DAEMON=1
SLOT=0
SANDBOX_WRITE=:/dev/console:/dev/fd:/dev/full:/dev/null:/dev/pts/:/dev/pty:/dev/shm:/dev/tts:/dev/tty:/dev/vc/:/dev/zero:/proc/self/fd:/tmp/:/usr/lib32/cf:/usr/lib32/conftest:/usr/lib64/cf:/usr/lib64/conftest:/usr/lib/cf:/usr/lib/conftest:/usr/tmp/cf:/usr/tmp/conftest:/var/tmp:/var/tmp/:/var/tmp/portage/sys-apps/sandbox-2.4/homedir/.bash_history
SANDBOX_LIB=libsandbox.so
ELIBC=glibc
LINGUAS=en_US en
SHELL=/bin/sh
TERM=screen
KERNEL=linux
KV=2.6.36-gentoo-r5
XDG_SESSION_COOKIE=d209e0650ffe67fde18419e94bf8e895-1304650290.725723-105440127
TMPDIR=/var/tmp/portage/sys-apps/sandbox-2.4/temp
CATEGORY=sys-apps
SSH_CLIENT=192.168.2.5 38142 22
CPPFLAGS=
PORT_ENOTICE_DIR=/var/tmp/portage/enotice/
FILESDIR=/usr/portage/sys-apps/sandbox/files
LD_PRELOAD=libsandbox.so
_E_DOCDESTTREE_=
EXEOPTIONS=-m0755
EBUILD_MASTER_PID=32719
ACCEPT_LICENSE=GPL-2
DESTTREE=/usr
SANDBOX_DEBUG=0
DUALCASE=1
DEFINED_PHASES= compile install postinst preinst test unpack
SSH_TTY=/dev/pts/0
SANDBOX_PREDICT=/var/tmp/portage/sys-apps/sandbox-2.4/homedir:/dev/crypto:/var/cache/fontconfig
PORTAGE_CONFIGROOT=/
LC_ALL=C
SANDBOX_PID=32638
ANT_HOME=/usr/share/ant
PROVIDE=
P=sandbox-2.4
ECLASSDIR=/usr/portage/eclass
_E_EXEDESTTREE_=
PORTAGE_ARCHLIST=ppc sparc64-freebsd ppc-openbsd x86-openbsd ppc64
x86-winnt x86-fbsd ppc-aix alpha arm x86-freebsd s390 amd64 arm-linux
x86-macos x64-openbsd ia64-hpux hppa x86-netbsd x86-cygwin amd64-linux
ia64-linux x86 sparc-solaris x64-freebsd sparc64-solaris x86-linux
x64-macos sparc m68k-mint ia64 mips ppc-macos x86-interix hppa-hpux
amd64-fbsd x64-solaris mips-irix m68k sh x86-solaris sparc-fbsd
PORTAGE_PYM_PATH=/usr/lib/portage/pym
http_proxy=http://192.168.2.5:8080
USE=consolekit elibc_glibc kernel_linux policykit userland_GNU x86
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
justin wrote: 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. It won't compile mpfr either. I get the same error. It appears that I can't compile ANYTHING right now. This ain't good. O_O Would doing this from a CD work or would I get the same error? I'm going to look for a binary. It's been a while so I'm not sure what was left on there. :/ Dale :-) :-)
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
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. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
Dale wrote: justin wrote: 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. It won't compile mpfr either. I get the same error. It appears that I can't compile ANYTHING right now. This ain't good. O_O Would doing this from a CD work or would I get the same error? I'm going to look for a binary. It's been a while so I'm not sure what was left on there. :/ Dale :-) :-) I found a binary for a older version. That seems to be working. I will run all the usual suspects, revdep-rebuild, python-updater and such and see what happens. Python-updater is making its list now. Still scratching my head on that one. Thanks for the help. Will post back if it gives any more problems. Dale :-) :-)
Re: [gentoo-user] Re: checking whether the C compiler works... no Oooops !!
Nikos Chantziaras wrote: On 05/06/2011 12:08 PM, Dale wrote: Nikos Chantziaras wrote: No, that's not it. It's this: !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-apps/sandbox-2.4/work/build-default/config.log Hmmm. Thought it was the same. Here goes but it is lengthy: [...] That shed any light? Yep: /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 :) On the list of things to do. Running python-updater now will run that next. Thanks. Dale :-) :-)
Re: [gentoo-user] Re: 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 :-) :-)
Re: [gentoo-user] Re: 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?
Re: [gentoo-user] Re: 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
Re: [gentoo-user] Re: 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.
Re: [gentoo-user] Re: 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 :-) :-)
Re: [gentoo-user] Re: 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
Re: [gentoo-user] Re: 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 :-) :-)
