在 2010年2月6日星期* 07:46:05，Harry Putnam 写道：
> Neil Bothwick <neil@digimed.co.uk> writes:
> > On Thu, 4 Feb 2010 22:13:20 +0800, Leon Feng wrote:
> >> I have seen this for weeks, but since I upgrade to portage-2.2* at the
> >> same time, do not know whether it is related. My revdep-rebuild out is
> >> listed below, anyone has a solution?
> >
> > Are you also running the testing gentoolkit? Otherwise you're trying to
> > use the old revdep-rebuild wit the new portage, which may have
> > unexpected consequences.
> >
> > Have you run lafilefixer --justfixit? This should always be the first
> > step when revdep-rebuild reports problems.
>
> You were speaking to Leon no me (The OP), but since my output was
> identical, I'll report too:
>
> I'm running ~x86 on everything and latest version of gentoolkit (I
> don't have gentoolkit-dev installed)
>
> I've emerged lafilefixer (thanks Steve) and ran
> lafilefixer --justfixit
>
> Then ran revdep-rebuild again.... it still finds broken binutils so
> I'm letting it `oneshot' the emerge.
>
> Was the expectation that running `lafilefixer --justfixit' would stop
> revdep-rebuild from continuously finding a broken binutils?
>
> Or was I expected to run lafilefixer --justfixit and then rebuild
> binutils once more?
>
> In any case I did the later and now the oneshot has finished and a
> rerun of revdep-rebuild again finds the same `broken' binutils....
>
> Apparently no progress has occurred..
>
Same here. I am running ~x86 too.
lafilefixer --justfixit and reemerged glibc do no work.
I will try out the patch in bug 298651 soon.
Leon
02-06-2010, 07:47 AM
Neil Bothwick
revdep-rebuild keeps reinstalling binutils
On Fri, 05 Feb 2010 17:46:05 -0600, Harry Putnam wrote:
> Was the expectation that running `lafilefixer --justfixit' would stop
> revdep-rebuild from continuously finding a broken binutils?
That sometimes happens as lafilefixer fixes some problems that
revdep-rebuild want to re-emerge to fix.
--
Neil Bothwick
02-07-2010, 05:05 AM
Konstantinos Bekiaris
revdep-rebuild keeps reinstalling binutils
On Wed, Feb 3, 2010 at 11:45 PM, Harry Putnam <reader@newsguy.com> wrote:
After todays update world, I run revdep-rebuild which reports binutils
broken and uses *`oneshot' to reinstall it. *Follow with another
revdep-rebuild and it finds the same thing.
Anyone seen something similar or have an idea what might be the problem?
I have a similar problem.To start with, i upgrade my system through emerge -uDN world and then i run emerge --depclean and revdep-rebuild. After that when i tried gcc/g++ i get: gcc-config: error: could not run/locate 'gcc'. Additionally, i noticed that there is a problem with python, because when*i try to use vi i get:** vi: error while loading shared libraries: libpython2.5.so.1.0: cannot open shared object file: No such file or directory. If i try to emerge -uDN world, the upgrade fails. Also, the revdep-rebuild fails. I attached a log. Any ideas?
Calculating dependencies ..... done!
>>> Creating Manifest for /usr/portage/media-sound/alsa-headers
>>> Creating Manifest for /usr/portage/dev-libs/libgpg-error
>>> Creating Manifest for /usr/portage/app-editors/nano
>>> Creating Manifest for /usr/portage/dev-libs/libgcrypt
>>> Creating Manifest for /usr/portage/sys-apps/util-linux
>>> Creating Manifest for /usr/portage/sys-devel/autoconf
>>> Creating Manifest for /usr/portage/sys-devel/libtool
>>> Creating Manifest for /usr/portage/sys-devel/automake
>>> Creating Manifest for /usr/portage/sys-process/psmisc
>>> Creating Manifest for /usr/portage/x11-misc/util-macros
>>> Downloading 'ftp://files.gentoo.gr/distfiles/tcl8.5.7-src.tar.gz'
--2010-02-06 19:52:28-- ftp://files.gentoo.gr/distfiles/tcl8.5.7-src.tar.gz
=> `/usr/portage/distfiles/tcl8.5.7-src.tar.gz'
Resolving files.gentoo.gr... 62.38.102.66
Connecting to files.gentoo.gr|62.38.102.66|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /distfiles ... done.
==> SIZE tcl8.5.7-src.tar.gz ... 4421720
==> PASV ... done. ==> REST 1823104 ... done.
==> RETR tcl8.5.7-src.tar.gz ... done.
Length: 2598616 (2.5M), 775512 (757K) remaining (unauthoritative)
* alsa-driver-1.0.21.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
You should enable -g (or higher) for debugging!
* CPV: media-sound/alsa-headers-1.0.21
* REPO: gentoo
* USE: amd64 elibc_glibc kernel_linux multilib test userland_GNU
>>> Unpacking source...
>>> Unpacking alsa-driver-1.0.21.tar.bz2 to /var/tmp/portage/media-sound/alsa-headers-1.0.21/work
* Applying alsa-headers-1.0.6a-user.patch ...
[ ok ]
>>> Source unpacked in /var/tmp/portage/media-sound/alsa-headers-1.0.21/work
>>> Compiling source in /var/tmp/portage/media-sound/alsa-headers-1.0.21/work/alsa-driver-1.0.21 ...
>>> Source compiled.
>>> Test phase [test]: media-sound/alsa-headers-1.0.21
make -j3 -j1 test
make: Nothing to be done for `test'.
>>> Install alsa-headers-1.0.21 into /var/tmp/portage/media-sound/alsa-headers-1.0.21/image/ category media-sound
>>> Completed installing alsa-headers-1.0.21 into /var/tmp/portage/media-sound/alsa-headers-1.0.21/image/
>>> Installing (1 of 81) media-sound/alsa-headers-1.0.21
>>> Emerging (2 of 81) dev-libs/libgpg-error-1.7
* libgpg-error-1.7.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
You should enable -g (or higher) for debugging!
* CPV: dev-libs/libgpg-error-1.7
* REPO: gentoo
* USE: amd64 elibc_glibc kernel_linux multilib nls test userland_GNU
>>> Unpacking source...
>>> Unpacking libgpg-error-1.7.tar.bz2 to /var/tmp/portage/dev-libs/libgpg-error-1.7/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libgpg-error-1.7/work
>>> Preparing source in /var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7 ...
* Removing useless C++ checks ...
[ ok ]
* Running elibtoolize in: libgpg-error-1.7
* Applying install-sh-1.5.4.patch ...
* Applying portage-1.5.10.patch ...
* Applying max_cmd_len-1.5.20.patch ...
* Applying sed-1.5.6.patch ...
* Applying as-needed-1.5.patch ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7 ...
* econf: updating libgpg-error-1.7/config.guess with /usr/share/gnuconfig/config.guess
* econf: updating libgpg-error-1.7/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --enable-nls
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
configure: autobuild project... libgpg-error
configure: autobuild revision... 1.7
configure: autobuild hostname... Gentoo
configure: autobuild timestamp... 20100206-195611
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7/config.log
* ERROR: dev-libs/libgpg-error-1.7 failed:
* econf failed
*
* Call stack:
* ebuild.sh, line 54: Called src_configure
* environment, line 2666: Called econf '--enable-nls'
* ebuild.sh, line 544: Called die
* The specific snippet of code:
* die "econf failed"
*
* If you need support, post the output of 'emerge --info =dev-libs/libgpg-error-1.7',
* the complete build log and the output of 'emerge -pqv =dev-libs/libgpg-error-1.7'.
* The complete build log is located at '/var/tmp/portage/dev-libs/libgpg-error-1.7/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-libs/libgpg-error-1.7/temp/environment'.
* S: '/var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7'
>>> Failed to emerge dev-libs/libgpg-error-1.7, Log file:
* IMPORTANT: 27 config files in '/etc' need updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files.
[32;01m*[0m Configuring search environment for revdep-rebuild
[32;01m*[0m Checking reverse dependencies
[32;01m*[0m Packages containing binaries and libraries broken by a package update
[32;01m*[0m will be emerged.
[32;01m*[0m Collecting system binaries and libraries
[32;01m*[0m Found existing 1_files.rr
[32;01m*[0m Collecting complete LD_LIBRARY_PATH
[32;01m*[0m Found existing 2_ldpath.rr.
[32;01m*[0m Checking dynamic linking consistency
[32;01m*[0m Found existing 3_broken.rr.
[32;01m*[0m Assigning files to packages
[32;01m*[0m Found existing 4_raw.rr
[32;01m*[0m Cleaning list of packages to rebuild
[32;01m*[0m Found existing 4_pkgs.rr
[32;01m*[0m Assigning packages to ebuilds
[32;01m*[0m Found existing 4_ebuilds.rr
[32;01m*[0m Evaluating package order
[32;01m*[0m Found existing 5_order.rr
[32;01m*[0m Generated new 5_order.rr
[32;01m*[0m All prepared. Starting rebuild
emerge --oneshot app-editors/vim:0
dev-lang/perl:0
sys-libs/cracklib:0
..........
Calculating dependencies ... done!
>>> Creating Manifest for /usr/portage/dev-lang/perl
>>> Creating Manifest for /usr/portage/sys-libs/cracklib
>>> Creating Manifest for /usr/portage/app-editors/vim
>>> Verifying ebuild manifests
>>> Starting parallel fetch
>>> Emerging (1 of 3) dev-lang/perl-5.8.8-r8
* perl-5.8.8.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
You should enable -g (or higher) for debugging!
* CPV: dev-lang/perl-5.8.8-r8
* REPO: gentoo
* USE: amd64 berkdb elibc_glibc gdbm kernel_linux multilib test userland_GNU
sandbox:main signal SIGQUIT already had a handler ...
>>> Unpacking source...
>>> Unpacking perl-5.8.8.tar.bz2 to /var/tmp/portage/dev-lang/perl-5.8.8-r8/work
* Applying perl-prelink-lpthread.patch ...
[ ok ]
* Applying perl-perldoc-emptydirs.patch ...
[ ok ]
* Applying perl-5.8.8-reorder-INC.patch ...
[ ok ]
* Applying perl-picdl.patch ...
[ ok ]
* Applying perl-noksh.patch ...
[ ok ]
* Applying perl-5.8.8-makedepend-syntax.patch ...
[ ok ]
* Applying perl-5.8.7-MakeMaker-RUNPATH.patch ...
[ ok ]
* Applying perl-hppa-pa7200-configure.patch ...
[ ok ]
* Applying perl-5.8.8-lib64.patch ...
[ ok ]
* Applying perl-5.8.8-USE_MM_LD_RUN_PATH.patch ...
[ ok ]
* Applying perl-5.8.8-links.patch ...
[ ok ]
* Applying perl-5.8.8-cplusplus.patch ...
[ ok ]
* Applying perl-5.8.8-gcc42-command-line.patch ...
[ ok ]
* Applying perl-5.8.8-asm-page-h-compile-failure.patch ...
[ ok ]
* Applying perl-fix_h2ph_include_quote.patch ...
[ ok ]
* Applying perl-5.8.8-perlcc.patch ...
[ ok ]
* Applying perl-5.8.8-libnet-hostname.patch ...
[ ok ]
* Applying perl-5.8.8-utf8-boundary.patch ...
[ ok ]
* Applying perl-5.8.8-CVE-2008-1927.patch ...
[ ok ]
* Applying perl-5.8.8-CAN-2005-0448-rmtree-2.patch ...
[ ok ]
* Applying perl-5.8.8-fix_file_path_chdir.patch ...
[ ok ]
* Applying perl-5.8.8-ccld-cflags.patch ...
[ ok ]
>>> Source unpacked in /var/tmp/portage/dev-lang/perl-5.8.8-r8/work
sandbox:main signal SIGQUIT already had a handler ...
>>> Compiling source in /var/tmp/portage/dev-lang/perl-5.8.8-r8/work/perl-5.8.8 ...
First let's make sure your kit is complete. Checking...
Locating common programs...
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.
Checking how to test for symbolic links...
You can test for symbolic links with 'test -h'.
Good, your tr supports [:lower:] and [:upper:] to convert case.
Using [:upper:] and [:lower:] to convert case.
gcc-config: error: could not run/locate 'x86_64-pc-linux-gnu-gcc'
You need to find a working C compiler.
Either (purchase and) install the C compiler supplied by your OS vendor,
or for a free C compiler try http://gcc.gnu.org/
I cannot continue any further, aborting.
* ERROR: dev-lang/perl-5.8.8-r8 failed:
* Unable to configure
*
* Call stack:
* ebuild.sh, line 54: Called src_compile
* environment, line 2800: Called src_configure
* environment, line 2883: Called die
* The specific snippet of code:
* sh Configure -des -Darchname="${myarch}" -Dcccdlflags='-fPIC' -Dccdlflags='-rdynamic' -Dcc="$(tc-getCC)" -Dprefix='/usr' -Dvendorprefix='/usr' -Dsiteprefix='/usr' -Dlocincpth=' ' -Doptimize="${CFLAGS}" -Duselargefiles -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dinstallman1dir=/usr/share/man/man1 -Dinstallman3dir=/usr/share/man/man3 -Dman1ext='1' -Dman3ext='3pm' -Dinc_version_list="$inclist" -Dcf_by='Gentoo' -Ud_csh -Dusenm "${myconf[@]}" || die "Unable to configure"
*
* If you need support, post the output of 'emerge --info =dev-lang/perl-5.8.8-r8',
* the complete build log and the output of 'emerge -pqv =dev-lang/perl-5.8.8-r8'.
* The complete build log is located at '/var/tmp/portage/dev-lang/perl-5.8.8-r8/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-lang/perl-5.8.8-r8/temp/environment'.
* S: '/var/tmp/portage/dev-lang/perl-5.8.8-r8/work/perl-5.8.8'
sandbox:main signal SIGQUIT already had a handler ...
>>> Failed to emerge dev-lang/perl-5.8.8-r8, Log file:
[33;01m*[0m
[33;01m*[0m revdep-rebuild failed to emerge all packages.
[33;01m*[0m you have the following choices:
[32;01m*[0m - If emerge failed during the build, fix the problems and re-run revdep-rebuild.
[32;01m*[0m - Use /etc/portage/package.keywords to unmask a newer version of the package.
[32;01m*[0m (and remove 5_order.rr to be evaluated again)
[32;01m*[0m - Modify the above emerge command and run it manually.
[32;01m*[0m - Compile or unmerge unsatisfied packages manually,
[32;01m*[0m remove temporary files, and try again.
[32;01m*[0m (you can edit package/ebuild list first)
[32;01m*[0m
[32;01m*[0m To remove temporary files, please run:
[32;01m*[0m rm /var/cache/revdep-rebuild/*.rr
02-07-2010, 07:41 PM
walt
revdep-rebuild keeps reinstalling binutils
On 02/06/2010 10:05 PM, Konstantinos Bekiaris wrote:
...i upgrade my system through emerge -uDN world and then i run emerge --depclean and revdep-rebuild. After that when i tried gcc/g++ i get: gcc-config: error: could not run/locate 'gcc'. Additionally, i noticed that
there is a problem with python, because when i try to use vi i get: vi: error while loading shared libraries: libpython2.5.so.1.0: cannot open shared object file: No such file or directory. If i try to emerge -uDN world, the upgrade fails. Also, the
revdep-rebuild fails. I attached a log. Any ideas?
I'm guessing that depclean removed some packages that are still needed.
Do you have python-2.6.4 on your machine? You should. What about
gcc-config-1.4.1 and gcc-4.3.4? vi is linked to an obsolete version
of python, so it needs to be re-emerged manually if revdep-rebuild
won't run properly. I'm guessing that vi may not be the only package
that's linked against an obsolete python library, so python-updater
may be worth a try.
02-07-2010, 08:18 PM
Konstantinos Bekiaris
revdep-rebuild keeps reinstalling binutils
On Sun, Feb 7, 2010 at 10:41 PM, walt <w41ter@gmail.com> wrote:
On 02/06/2010 10:05 PM, Konstantinos Bekiaris wrote:
...i upgrade my system through emerge -uDN world and then i run emerge --depclean and revdep-rebuild. After that when i tried gcc/g++ i get: gcc-config: error: could not run/locate 'gcc'. Additionally, i noticed that
there is a problem with python, because when i try to use vi i get: * vi: error while loading shared libraries: libpython2.5.so.1.0: cannot open shared object file: No such file or directory. If i try to emerge -uDN world, the upgrade fails. Also, the
revdep-rebuild fails. I attached a log. Any ideas?
I'm guessing that depclean removed some packages that are still needed.
Do you have python-2.6.4 on your machine? *You should. *What about
gcc-config-1.4.1 and gcc-4.3.4? *vi is linked to an obsolete version
of python, so it needs to be re-emerged manually if revdep-rebuild
won't run properly. *I'm guessing that vi may not be the only package
that's linked against an obsolete python library, so python-updater
may be worth a try.
Ok, nice approach. The problem is that no package can be installed because the compiler gcc is not working...this is Gentoo...everything has to do with compiling. The solution of the problem starts with fixing gcc by hand. (You are right about python, i have an older version).So?
02-08-2010, 02:48 AM
Keith Dart
revdep-rebuild keeps reinstalling binutils
=== On Sun, 02/07, Konstantinos Bekiaris wrote: ===
> Ok, nice approach. The problem is that no package can be installed
> because the compiler gcc is not working...this is Gentoo...everything
> has to do with compiling. The solution of the problem starts with
> fixing gcc by hand. (You are right about python, i have an older
> version).So?
===
try gcc-config first. See if that clears it up. then
"source /etc/profile".
-- Keith Dart
--
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
Keith Dart <keith@dartworks.biz>
public key: ID: 19017044
<http://www.dartworks.biz/>
================================================== ===================
02-08-2010, 05:19 AM
Konstantinos Bekiaris
revdep-rebuild keeps reinstalling binutils
On Mon, Feb 8, 2010 at 5:48 AM, Keith Dart <keith@dartworks.biz> wrote:
=== On Sun, 02/07, Konstantinos Bekiaris wrote: ===
> Ok, nice approach. The problem is that no package can be installed
> because the compiler gcc is not working...this is Gentoo...everything
> has to do with compiling. The solution of the problem starts with
> fixing gcc by hand. (You are right about python, i have an older
> version).So?
===
try gcc-config first. See if that clears it up. then
"source /etc/profile".
I think we are close to the problem. However, whatever i try, i get:
Gentoo kostas # gcc-config -l** gcc-config: Active gcc profile is invalid!
*[1] x86_64-pc-linux-gnu-4.3.4
Gentoo kostas # gcc-config -E** gcc-config: Active gcc profile is invalid!*[1] x86_64-pc-linux-gnu-4.3.4Gentoo kostas # gcc-config -B** gcc-config: Active gcc profile is invalid!
*[1] x86_64-pc-linux-gnu-4.3.4Gentoo kostas # gcc-config -X** gcc-config: Active gcc profile is invalid!*[1] x86_64-pc-linux-gnu-4.3.4
02-08-2010, 07:50 PM
walt
revdep-rebuild keeps reinstalling binutils
On 02/07/2010 10:19 PM, Konstantinos Bekiaris wrote:
On Mon, Feb 8, 2010 at 5:48 AM, Keith Dart <keith@dartworks.biz <mailto:keith@dartworks.biz>> wrote:
=== On Sun, 02/07, Konstantinos Bekiaris wrote: ===
> Ok, nice approach. The problem is that no package can be installed
> because the compiler gcc is not working...this is Gentoo...everything
> has to do with compiling. The solution of the problem starts with
> fixing gcc by hand. (You are right about python, i have an older
> version).So?
===
try gcc-config first. See if that clears it up. then
"source /etc/profile".
I think we are close to the problem. However, whatever i try, i get:
Gentoo kostas # gcc-config -l
* gcc-config: Active gcc profile is invalid!
[1] x86_64-pc-linux-gnu-4.3.4
drwxr-xr-x 2 root root 4096 Jan 24 13:16 .drwxr-xr-x 5 root root 4096 Jan 24 13:17 ..lrwxrwxrwx 1 root root * 25 Jan 24 06:25 .NATIVE -> x86_64-pc-linux-gnu-4.1.2
-rw-r--r-- 1 root root * 34 Jan 24 06:25 config-x86_64-pc-linux-gnu-rw-r--r-- 1 root root *381 Jan 24 06:25 x86_64-pc-linux-gnu-4.3.4
I think that i have gcc, the problem is that it is not correctly linked with tha appropriate files-libraries.
02-09-2010, 05:53 PM
walt
revdep-rebuild keeps reinstalling binutils
On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
drwxr-xr-x 2 root root 4096 Jan 24 13:16 .
drwxr-xr-x 5 root root 4096 Jan 24 13:17 ..
lrwxrwxrwx 1 root root 25 Jan 24 06:25 .NATIVE -> x86_64-pc-linux-gnu-4.1.2
-rw-r--r-- 1 root root 34 Jan 24 06:25 config-x86_64-pc-linux-gnu
-rw-r--r-- 1 root root 381 Jan 24 06:25 x86_64-pc-linux-gnu-4.3.4
There's one problem. .NATIVE is pointing at a non-existent file. Assuming
your machine really does have gcc-4.3.4, .NATIVE should be pointing at
x86_64-pc-linux-gnu-4.3.4, and the contents of config-x86_64-pc-linux-gnu
should be: CURRENT=x86_64-pc-linux-gnu-4.3.4
I don't know why there are two different ways to point at the same gcc, but
that's the way gcc-config does it.
Correct those two files and see if it helps.
I think that i have gcc, the problem is that it is not correctly linked
> with tha appropriate files-libraries.
You can run /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/gcc directly to see if
it works.
revdep-rebuild keeps reinstalling binutils
