[gentoo-user] revdep-rebuild keeps reinstalling binutils

[gentoo-user] revdep-rebuild keeps reinstalling binutils

[Harry Putnam]

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?  

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Alan McKinnon]

On Wednesday 03 February 2010 23:45:00 Harry Putnam 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?

full output from revdep-rebuild?

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Steven]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15:45/02/03/10, Harry Putnam 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?  
>

Sounds like your haveing a similar problem to what I have been haveing
for the last few weeks now. Can you post the output of revdep-rebuild.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iF4EAREIAAYFAktp9M4ACgkQpSa/g4Qb1ZlxfwD/XGRzyLO+2tFs5ZyfU7s3Aj3u
gOFbNS5daghWSpahrL8A/0R1fGvJLrges3AhXYBcyWwz8LgCHx+lw8gmzPbG8dg9
=2L6r
-----END PGP SIGNATURE-----

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Leon Feng]

在 2010/2/4 05:45:00，Harry Putnam ：
> 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 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?

# revdep-rebuild -p 
[...]
 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Generated new 2_ldpath.rr
 * Checking dynamic linking consistency
[ 35% ]  *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la 
(requires -liberty)
 *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la 
(requires -liberty) 
[ 100% ]
 * Generated new 3_broken.rr
 * Assigning files to packages
 *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la -> sys-devel/binutils
 *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la -> sys-
devel/binutils
 * Generated new 4_raw.rr and 4_owners.rr
 * Cleaning list of packages to rebuild
 * Generated new 4_pkgs.rr
 * Assigning packages to ebuilds
 * Generated new 4_ebuilds.rr
 * Evaluating package order
 * Generated new 5_order.rr
 * All prepared. Starting rebuild
emerge --oneshot --pretend  sys-devel/binutils:0

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/binutils-2.20
 * Now you can remove -p (or --pretend) from arguments and re-run revdep-
rebuild.

Leon Feng

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Helmut Jarausch]

Hi Leon,

have you really run 
lafilefixer --justfixit

and some time, ago, I had problems because of
dangling symlinks, so I've run

symlinks -dr /usr

(which remove all dangling symlinks in /usr/**/*)

Then re-emerge sys-devel/binutils again

I hope this helps,m

Helmut.


On  4 Feb, Leon Feng wrote:
> 在 2010/2/4 05:45:00，Harry Putnam ：
>> 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 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?
> 
> # revdep-rebuild -p 
> [...]
>  * Collecting system binaries and libraries
>  * Generated new 1_files.rr
>  * Collecting complete LD_LIBRARY_PATH
>  * Generated new 2_ldpath.rr
>  * Checking dynamic linking consistency
> [ 35% ]  *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la 
> (requires -liberty)
>  *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la 
> (requires -liberty) 
> [ 100% ]
>  * Generated new 3_broken.rr
>  * Assigning files to packages
>  *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la -> sys-devel/binutils
>  *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la -> sys-
> devel/binutils
>  * Generated new 4_raw.rr and 4_owners.rr
>  * Cleaning list of packages to rebuild
>  * Generated new 4_pkgs.rr
>  * Assigning packages to ebuilds
>  * Generated new 4_ebuilds.rr
>  * Evaluating package order
>  * Generated new 5_order.rr
>  * All prepared. Starting rebuild
> emerge --oneshot --pretend  sys-devel/binutils:0
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-devel/binutils-2.20
>  * Now you can remove -p (or --pretend) from arguments and re-run revdep-
> rebuild.
> 
> Leon Feng

-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

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.


-- 
Neil Bothwick

If a man is standing in the middle of the forest speaking and there is
no woman around to hear him - Is he still wrong?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On Wednesday 03 February 2010 23:45:00 Harry Putnam 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?
>
> full output from revdep-rebuild?

My output is identical to that posted by Leon F.

Where does one find find lafilefixer?

  root # which lafilefixer

which: no lafilefixer in
(/usr/local/bin:/cvsb/reader/home/reader/scripts:/cvsb/reader/home/reader/scripts/perl:/cvsb/reader/home/reader/scripts/awk:/cvsb/reader/home/reader/scripts/log_tools:/root/bin:/cvsb/reader/root/bin:/usr/local/sbin:/usr/share/doc/gentoolkit-0.2.1_rc2/deprecated/qpkg:/usr/share/doc/gentoolkit-0.2.1_rc2/deprecated/etcat:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.3.4)

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Doug Hunley]

On Thu, Feb 4, 2010 at 13:11, Harry Putnam <reader@newsguy.com> wrote:
> Where does one find find lafilefixer?

emerge  dev-util/lafilefixer



-- 
Douglas J Hunley, RHCT
doug.hunley@gmail.com : http://douglasjhunley.com : Twitter: @hunleyd

Obsessively opposed to the typical.

Re: [gentoo-user] revdep-rebuild keeps reinstalling binutils

[Steven]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22:13/02/04/10, Leon Feng wrote:
> ??? 2010/2/4 05:45:00???Harry Putnam ???
> > 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 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?
> 
> # revdep-rebuild -p 
> [...]
>  * Collecting system binaries and libraries
>  * Generated new 1_files.rr
>  * Collecting complete LD_LIBRARY_PATH
>  * Generated new 2_ldpath.rr
>  * Checking dynamic linking consistency
> [ 35% ]  *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la 
> (requires -liberty)
>  *   broken /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la 
> (requires -liberty) 
> [ 100% ]
>  * Generated new 3_broken.rr
>  * Assigning files to packages
>  *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libbfd.la -> sys-devel/binutils
>  *   /usr/lib/binutils/i686-pc-linux-gnu/2.20/libopcodes.la -> sys-
> devel/binutils
>  * Generated new 4_raw.rr and 4_owners.rr
>  * Cleaning list of packages to rebuild
>  * Generated new 4_pkgs.rr
>  * Assigning packages to ebuilds
>  * Generated new 4_ebuilds.rr
>  * Evaluating package order
>  * Generated new 5_order.rr
>  * All prepared. Starting rebuild
> emerge --oneshot --pretend  sys-devel/binutils:0
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-devel/binutils-2.20
>  * Now you can remove -p (or --pretend) from arguments and re-run revdep-
> rebuild.
> 
> Leon Feng

Bug#:	298651
- -- 
public key @
apartment415.homelinux.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iF4EAREIAAYFAktrMZgACgkQpSa/g4Qb1Zm/AgEAoJ8UQR4+4vIw8TlprXuHuFEU
tcKakeyF/TOzs91VbuUA/jAuetZ3l2HE1qbCvHzh0G/HQzBYTeLQCEGuPJo8mksF
=BTwn
-----END PGP SIGNATURE-----

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[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..

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Leon Feng]

在 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

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Harry Putnam]

Leon Feng <rainofchaos@gmail.com> writes:

[...]

>> 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, sorry to be a lamer here but I didn't understand the patch or
even that there was an actual patch, after reading the long confusing
exchange on that bug report.

Did you come away with a semi-easily done patch?  If so can you
explain a bit about how its applied or maybe direct me to the part
that discusses an actual patch?

ps - have you see something detrimental happening if you just go ahead
and run like it is?

[gentoo-user] revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1.1: Type: text/plain, Size: 903 bytes --]

  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?

[-- Attachment #1.2: Type: text/html, Size: 1278 bytes --]

[-- Attachment #2: Revdep-rebuild.txt --]
[-- Type: text/plain, Size: 26317 bytes --]

Calculating dependencies  ..\b\b... 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)

        [ skipping 1750K ]
  1750K ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, .......... .......... 70% 47.8K 39s
  1800K .......... .......... .......... .......... .......... 72% 39.0K 23s
  1850K .......... .......... .......... .......... .......... 74% 39.0K 19s
  1900K .......... .......... .......... .......... .......... 76% 63.4K 15s
  1950K .......... .......... .......... .......... .......... 78% 49.2K 13s
  2000K .......... .......... .......... .......... .......... 80% 45.2K 12s
  2050K .......... .......... .......... .......... .......... 82% 48.0K 10s
  2100K .......... .......... .......... .......... .......... 84% 46.2K 9s
  2150K .......... .......... .......... .......... .......... 86% 44.6K 8s
  2200K .......... .......... .......... .......... .......... 88% 57.2K 7s
  2250K .......... .......... .......... .......... .......... 90% 44.3K 5s
  2300K .......... .......... .......... .......... .......... 92% 29.0K 4s
  2350K .......... .......... .......... .......... .......... 94% 73.0K 3s
  2400K .......... .......... .......... .......... .......... 96% 44.5K 2s
  2450K .......... .......... .......... .......... .......... 98% 47.7K 1s
  2500K .......... .......... .......... .......... ..........100% 47.6K 0s
  2550K .......... .......... .......... .......... ..........102% 44.7K 0s
  2600K .......... .......... .......... .......... ..........104% 46.5K -2s
  2650K .......... .......... .......... .......... ..........106% 36.9K -3s
  2700K .......... .......... .......... .......... ..........108% 50.1K -4s
  2750K .......... .......... .......... .......... ..........110% 45.5K -5s
  2800K .......... .......... .......... .......... ..........112% 44.8K -6s
  2850K .......... .......... .......... .......... ..........114% 45.2K -7s
  2900K .......... .......... .......... .......... ..........116% 45.6K -8s
  2950K .......... .......... .......... .......... ..........118% 35.3K -10s
  3000K .......... .......... .......... .......... ..........120% 87.7K -10s
  3050K .......... .......... .......... .......... ..........122% 51.3K -11s
  3100K .......... .......... .......... .......... ..........124% 50.8K -13s
  3150K .......... .......... .......... .......... ..........126% 42.0K -14s
  3200K .......... .......... .......... .......... ..........128% 44.2K -15s
  3250K .......... .......... .......... .......... ..........130% 44.6K -16s
  3300K .......... .......... .......... .......... ..........132% 40.1K -17s
  3350K .......... .......... .......... .......... ..........133% 43.8K -18s
  3400K .......... .......... .......... .......... ..........135% 45.5K -19s
  3450K .......... .......... .......... .......... ..........137% 50.8K -20s
  3500K .......... .......... .......... .......... ..........139% 58.4K -21s
  3550K .......... .......... .......... .......... ..........141% 56.0K -22s
  3600K .......... .......... .......... .......... ..........143% 47.2K -23s
  3650K .......... .......... .......... .......... ..........145% 45.6K -25s
  3700K .......... .......... .......... .......... ..........147% 48.4K -26s
  3750K .......... .......... .......... .......... ..........149% 44.4K -27s
  3800K .......... .......... .......... .......... ..........151% 49.8K -28s
  3850K .......... .......... .......... .......... ..........153% 42.5K -29s
  3900K .......... .......... .......... .......... ..........155% 52.7K -30s
  3950K .......... .......... .......... .......... ..........157% 44.4K -31s
  4000K .......... .......... .......... .......... ..........159% 49.8K -32s
  4050K .......... .......... .......... .......... ..........161% 46.6K -33s
  4100K .......... .......... .......... .......... ..........163% 50.5K -34s
  4150K .......... .......... .......... .......... ..........165% 49.7K -35s
  4200K .......... .......... .......... .......... ..........167% 51.7K -36s
  4250K .......... .......... .......... .......... ..........169% 7.45K -41s
  4300K .......... ........                                   170% 3.08K=66s

2010-02-06 19:53:38 (38.4 KB/s) - `/usr/portage/distfiles/tcl8.5.7-src.tar.gz' saved [4421720]

 * tcl8.5.7-src.tar.gz RMD160 SHA1 SHA256 size ;-) ...                   [ ok ]
>>> Creating Manifest for /usr/portage/dev-lang/tcl
>>> Creating Manifest for /usr/portage/dev-scheme/guile
>>> Creating Manifest for /usr/portage/dev-libs/openssl
>>> Creating Manifest for /usr/portage/net-nds/openldap
>>> Creating Manifest for /usr/portage/app-admin/eselect
>>> Creating Manifest for /usr/portage/sys-libs/pam
>>> Creating Manifest for /usr/portage/media-libs/alsa-lib
>>> Creating Manifest for /usr/portage/dev-java/javacup
>>> Creating Manifest for /usr/portage/dev-java/xml-commons-external
>>> Creating Manifest for /usr/portage/dev-java/bcel
>>> Creating Manifest for /usr/portage/dev-java/xjavac
>>> Creating Manifest for /usr/portage/dev-java/xml-commons-resolver
>>> Creating Manifest for /usr/portage/dev-java/xalan-serializer
>>> Creating Manifest for /usr/portage/dev-java/xerces
>>> Creating Manifest for /usr/portage/dev-java/xalan
>>> Creating Manifest for /usr/portage/dev-java/ant-junit
>>> Creating Manifest for /usr/portage/dev-java/javacc
>>> Creating Manifest for /usr/portage/x11-proto/xproto
>>> Creating Manifest for /usr/portage/app-admin/eselect-python
>>> Creating Manifest for /usr/portage/dev-libs/libxml2
>>> Creating Manifest for /usr/portage/dev-libs/libgamin
>>> Creating Manifest for /usr/portage/dev-libs/libxslt
>>> Creating Manifest for /usr/portage/sys-devel/autogen
>>> Creating Manifest for /usr/portage/app-admin/gamin
>>> Creating Manifest for /usr/portage/app-admin/gam-server
>>> Creating Manifest for /usr/portage/dev-libs/glib
>>> Creating Manifest for /usr/portage/sys-libs/db
>>> Creating Manifest for /usr/portage/x11-proto/inputproto
>>> Creating Manifest for /usr/portage/x11-libs/libXau
>>> Creating Manifest for /usr/portage/x11-proto/xextproto
>>> Creating Manifest for /usr/portage/x11-libs/xtrans
>>> Creating Manifest for /usr/portage/x11-libs/libICE
>>> Creating Manifest for /usr/portage/x11-libs/libSM
>>> Creating Manifest for /usr/portage/x11-libs/libXdmcp
>>> Creating Manifest for /usr/portage/x11-proto/kbproto
>>> Creating Manifest for /usr/portage/dev-libs/libpthread-stubs
>>> Creating Manifest for /usr/portage/x11-proto/renderproto
>>> Creating Manifest for /usr/portage/x11-proto/bigreqsproto
>>> Creating Manifest for /usr/portage/x11-proto/xcmiscproto
>>> Creating Manifest for /usr/portage/x11-proto/xf86bigfontproto
>>> Creating Manifest for /usr/portage/x11-proto/xcb-proto
>>> Creating Manifest for /usr/portage/x11-libs/libxcb
>>> Creating Manifest for /usr/portage/x11-libs/libX11
>>> Creating Manifest for /usr/portage/media-libs/freetype
>>> Creating Manifest for /usr/portage/media-libs/fontconfig
>>> Creating Manifest for /usr/portage/app-admin/eselect-fontconfig
>>> Creating Manifest for /usr/portage/x11-libs/libXt
>>> Creating Manifest for /usr/portage/sys-apps/dbus
>>> Creating Manifest for /usr/portage/media-libs/giflib
>>> Creating Manifest for /usr/portage/dev-libs/dbus-glib
>>> Creating Manifest for /usr/portage/sys-auth/consolekit
>>> Creating Manifest for /usr/portage/sys-auth/pambase
>>> Creating Manifest for /usr/portage/x11-libs/libXext
>>> Creating Manifest for /usr/portage/x11-libs/libXmu
>>> Creating Manifest for /usr/portage/x11-apps/xauth
>>> Creating Manifest for /usr/portage/net-misc/openssh
>>> Creating Manifest for /usr/portage/x11-libs/libXrender
>>> Creating Manifest for /usr/portage/x11-libs/libXft
>>> Creating Manifest for /usr/portage/dev-lang/tk
>>> Creating Manifest for /usr/portage/dev-tcltk/expect
>>> Creating Manifest for /usr/portage/dev-util/dejagnu
>>> Creating Manifest for /usr/portage/sys-devel/binutils
>>> Creating Manifest for /usr/portage/dev-libs/libffi
>>> Creating Manifest for /usr/portage/sys-devel/gcc
>>> Creating Manifest for /usr/portage/x11-libs/libXpm
>>> Creating Manifest for /usr/portage/x11-libs/libXi
>>> Creating Manifest for /usr/portage/x11-proto/recordproto
>>> Creating Manifest for /usr/portage/x11-libs/libXaw
>>> Creating Manifest for /usr/portage/x11-libs/libXtst
>>> Creating Manifest for /usr/portage/dev-java/icedtea6-bin
>>> Creating Manifest for /usr/portage/sys-apps/groff

>>> Verifying ebuild manifests

>>> Starting parallel fetch

>>> Emerging (1 of 81) media-sound/alsa-headers-1.0.21
>>> Downloading 'ftp://files.gentoo.gr/distfiles/alsa-driver-1.0.21.tar.bz2'
--2010-02-06 19:53:47--  ftp://files.gentoo.gr/distfiles/alsa-driver-1.0.21.tar.bz2
           => `/usr/portage/distfiles/alsa-driver-1.0.21.tar.bz2'
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 alsa-driver-1.0.21.tar.bz2 ... 3112563
==> PASV ... done.    ==> RETR alsa-driver-1.0.21.tar.bz2 ... done.
Length: 3112563 (3.0M) (unauthoritative)

     0K .......... .......... .......... .......... ..........  1% 31.5K 95s
    50K .......... .......... .......... .......... ..........  3% 38.4K 85s
   100K .......... .......... .......... .......... ..........  4% 76.1K 68s
   150K .......... .......... .......... .......... ..........  6% 29.0K 75s
   200K .......... .......... .......... .......... ..........  8% 76.0K 66s
   250K .......... .......... .......... .......... ..........  9% 49.1K 63s
   300K .......... .......... .......... .......... .......... 11% 44.6K 62s
   350K .......... .......... .......... .......... .......... 13% 43.0K 61s
   400K .......... .......... .......... .......... .......... 14% 42.5K 60s
   450K .......... .......... .......... .......... .......... 16% 33.6K 60s
   500K .......... .......... .......... .......... .......... 18% 42.0K 59s
   550K .......... .......... .......... .......... .......... 19% 47.3K 58s
   600K .......... .......... .......... .......... .......... 21% 41.0K 57s
   650K .......... .......... .......... .......... .......... 23% 45.4K 55s
   700K .......... .......... .......... .......... .......... 24% 48.3K 53s
   750K .......... .......... .......... .......... .......... 26% 49.9K 52s
   800K .......... .......... .......... .......... .......... 27% 27.1K 52s
   850K .......... .......... .......... .......... .......... 29% 25.2K 53s
   900K .......... .......... .......... .......... .......... 31% 32.9K 52s
   950K .......... .......... .......... .......... .......... 32% 34.1K 52s
  1000K .......... .......... .......... .......... .......... 34% 31.7K 51s
  1050K .......... .......... .......... .......... .......... 36% 34.5K 50s
  1100K .......... .......... .......... .......... .......... 37% 46.0K 48s
  1150K .......... .......... .......... .......... .......... 39% 39.2K 47s
  1200K .......... .......... .......... .......... .......... 41% 41.3K 46s
  1250K .......... .......... .......... .......... .......... 42% 37.6K 44s
  1300K .......... .......... .......... .......... .......... 44% 34.1K 43s
  1350K .......... .......... .......... .......... .......... 46% 34.0K 42s
  1400K .......... .......... .......... .......... .......... 47% 36.4K 41s
  1450K .......... .......... .......... .......... .......... 49% 27.3K 40s
  1500K .......... .......... .......... .......... .......... 50% 24.4K 40s
  1550K .......... .......... .......... .......... .......... 52% 20.7K 39s
  1600K .......... .......... .......... .......... .......... 54% 22.5K 39s
  1650K .......... .......... .......... .......... .......... 55% 39.3K 37s
  1700K .......... .......... .......... .......... .......... 57% 53.9K 36s
  1750K .......... .......... .......... .......... .......... 59% 37.9K 34s
  1800K .......... .......... .......... .......... .......... 60% 30.5K 33s
  1850K .......... .......... .......... .......... .......... 62% 49.2K 31s
  1900K .......... .......... .......... .......... .......... 64% 29.0K 30s
  1950K .......... .......... .......... .......... .......... 65% 39.5K 29s
  2000K .......... .......... .......... .......... .......... 67% 29.8K 27s
  2050K .......... .......... .......... .......... .......... 69% 31.6K 26s
  2100K .......... .......... .......... .......... .......... 70% 39.1K 25s
  2150K .......... .......... .......... .......... .......... 72% 22.8K 24s
  2200K .......... .......... .......... .......... .......... 74% 76.5K 22s
  2250K .......... .......... .......... .......... .......... 75% 30.6K 21s
  2300K .......... .......... .......... .......... .......... 77% 27.1K 19s
  2350K .......... .......... .......... .......... .......... 78% 25.7K 18s
  2400K .......... .......... .......... .......... .......... 80% 34.3K 17s
  2450K .......... .......... .......... .......... .......... 82% 23.3K 15s
  2500K .......... .......... .......... .......... .......... 83% 20.7K 14s
  2550K .......... .......... .......... .......... .......... 85% 23.5K 13s
  2600K .......... .......... .......... .......... .......... 87% 23.4K 12s
  2650K .......... .......... .......... .......... .......... 88% 17.4K 10s
  2700K .......... .......... .......... .......... .......... 90% 17.7K 9s
  2750K .......... .......... .......... .......... .......... 92% 22.5K 7s
  2800K .......... .......... .......... .......... .......... 93% 25.0K 6s
  2850K .......... .......... .......... .......... .......... 95% 53.8K 4s
  2900K .......... .......... .......... .......... .......... 97% 32.4K 3s
  2950K .......... .......... .......... .......... .......... 98% 23.4K 1s
  3000K .......... .......... .......... .........            100% 13.5K=96s

2010-02-06 19:55:27 (31.7 KB/s) - `/usr/portage/distfiles/alsa-driver-1.0.21.tar.bz2' saved [3112563]

 * 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:

>>>  '/var/tmp/portage/dev-libs/libgpg-error-1.7/temp/build.log'

 * Messages for package dev-libs/libgpg-error-1.7:


 * GNU info directory index is up-to-date.

 * 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
\a.\a.\a.\a.\a.\a.\a.\a.\a.\a.
Calculating dependencies  \b\b... 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:

>>>  '/var/tmp/portage/dev-lang/perl-5.8.8-r8/temp/build.log'

 * Messages for package dev-lang/perl-5.8.8-r8:

 ^[[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

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[walt]

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.

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 1828 bytes --]

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Keith Dart]

=== 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/>
   =====================================================================

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

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.4
Gentoo kostas # gcc-config -B
 * gcc-config: Active gcc profile is invalid!
 [1] x86_64-pc-linux-gnu-4.3.4
Gentoo kostas # gcc-config -X
 * gcc-config: Active gcc profile is invalid!
 [1] x86_64-pc-linux-gnu-4.3.4

[-- Attachment #2: Type: text/html, Size: 1549 bytes --]

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[walt]

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

What do you have in /etc/env.d/gcc/?  I have this:

#ls -l /etc/env.d/gcc/
total 16
-rw-r--r-- 1 root root  32 2010-02-08 11:53 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root 235 2009-01-29 12:33 i686-pc-linux-gnu-4.1.2
-rw-r--r-- 1 root root 235 2009-07-04 09:02 i686-pc-linux-gnu-4.3.2
-rw-r--r-- 1 root root 235 2010-01-10 12:29 i686-pc-linux-gnu-4.3.4

Do you still have any version of gcc installed?

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

>
> What do you have in /etc/env.d/gcc/?  I have this:
>
> #ls -l /etc/env.d/gcc/
> total 16
> -rw-r--r-- 1 root root  32 2010-02-08 11:53 config-i686-pc-linux-gnu
> -rw-r--r-- 1 root root 235 2009-01-29 12:33 i686-pc-linux-gnu-4.1.2
> -rw-r--r-- 1 root root 235 2009-07-04 09:02 i686-pc-linux-gnu-4.3.2
> -rw-r--r-- 1 root root 235 2010-01-10 12:29 i686-pc-linux-gnu-4.3.4
>
> Do you still have any version of gcc installed?
>
> 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.

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[walt]

On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
>     What do you have in /etc/env.d/gcc/?  I have this:
>
>     #ls -l /etc/env.d/gcc/
>     total 16
>     -rw-r--r-- 1 root root  32 2010-02-08 11:53 config-i686-pc-linux-gnu
>     -rw-r--r-- 1 root root 235 2009-01-29 12:33 i686-pc-linux-gnu-4.1.2
>     -rw-r--r-- 1 root root 235 2009-07-04 09:02 i686-pc-linux-gnu-4.3.2
>     -rw-r--r-- 1 root root 235 2010-01-10 12:29 i686-pc-linux-gnu-4.3.4
>
>     Do you still have any version of gcc installed?
>
> 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.

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Tue, Feb 9, 2010 at 8:53 PM, walt <w41ter@gmail.com> wrote:

> On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
>
>>    What do you have in /etc/env.d/gcc/?  I have this:
>>
>>    #ls -l /etc/env.d/gcc/
>>    total 16
>>    -rw-r--r-- 1 root root  32 2010-02-08 11:53 config-i686-pc-linux-gnu
>>    -rw-r--r-- 1 root root 235 2009-01-29 12:33 i686-pc-linux-gnu-4.1.2
>>    -rw-r--r-- 1 root root 235 2009-07-04 09:02 i686-pc-linux-gnu-4.3.2
>>    -rw-r--r-- 1 root root 235 2010-01-10 12:29 i686-pc-linux-gnu-4.3.4
>>
>>    Do you still have any version of gcc installed?
>>
>> 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.
>
>
> It works, when i am in the folder /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/
> and i tried ./gcc, it works. Can you please show me the way  i must put the
> links in order to work from anywhere(sym links or hard links)? I think it is
> ln -s //usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/gcc " folder".

[-- Attachment #2: Type: text/html, Size: 2483 bytes --]

[gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[walt]

Konstantinos Bekiaris wrote:
> 
> 
> On Tue, Feb 9, 2010 at 8:53 PM, walt <w41ter@gmail.com
> <mailto:w41ter@gmail.com>> wrote:
> 
>     On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
> 
>            What do you have in /etc/env.d/gcc/?  I have this:
> 
>            #ls -l /etc/env.d/gcc/
>            total 16
>            -rw-r--r-- 1 root root  32 2010-02-08 11:53
>         config-i686-pc-linux-gnu
>            -rw-r--r-- 1 root root 235 2009-01-29 12:33
>         i686-pc-linux-gnu-4.1.2
>            -rw-r--r-- 1 root root 235 2009-07-04 09:02
>         i686-pc-linux-gnu-4.3.2
>            -rw-r--r-- 1 root root 235 2010-01-10 12:29
>         i686-pc-linux-gnu-4.3.4
> 
>            Do you still have any version of gcc installed?
> 
>         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.
> 
> 
>     It works, when i am in the folder
>     /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/ and i tried ./gcc, it works.
>     Can you please show me the way  i must put the links in order to
>     work from anywhere(sym links or hard links)? I think it is ln -s
>     //usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/gcc " folder".

This is weird.  I have a small binary /usr/bin/gcc which is obviously just
a stub for starting the version of gcc you select with gcc-config.  The
weird part is that no package claims that file so I don't know how it got
there but the date suggests it was put there by gcc-4.3.4.

$ls -l /usr/bin/gcc*
-rwxr-xr-x 1 root root  9572 2010-01-10 12:29 /usr/bin/gcc   <******* this one
lrwxrwxrwx 1 root root    58 2009-01-29 12:34 /usr/bin/gcc-4.1.2 -> /usr/i686-pc-linux-gnu/gcc-bin/4.1.2/i686-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root    58 2009-07-04 09:03 /usr/bin/gcc-4.3.2 -> /usr/i686-pc-linux-gnu/gcc-bin/4.3.2/i686-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root    58 2010-01-10 12:29 /usr/bin/gcc-4.3.4 -> /usr/i686-pc-linux-gnu/gcc-bin/4.3.4/i686-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 21711 2010-02-13 14:33 /usr/bin/gcc-config

Do you have a similar /usr/bin/gcc?  It seems to run whatever file
/etc/env.d/gcc/.NATIVE is pointing to, so that symlink must be right for
/usr/bin/gcc to work properly.

RE: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

kostas@Gentoo /usr/bin $ ls -al gcc*
-rwxr-xr-x 1 root root 14504 Jun 17  2008 gcc
lrwxrwxrwx 1 root root    62 Jan 24 06:25 gcc-4.3.4 -> /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/x86_64-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 21711 Jan 24 01:46 gcc-config
kostas@Gentoo /usr/bin $

Maybe I have to boot from a live cd, chroot to the hard-disk files, emerge gcc, reboot and after that emerge -uDN world. Gcc seems to be ok from here, the problems is somewhere else.


-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of walt
Sent: Sunday, February 14, 2010 1:18 AM
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

Konstantinos Bekiaris wrote:
> 
> 
> On Tue, Feb 9, 2010 at 8:53 PM, walt <w41ter@gmail.com
> <mailto:w41ter@gmail.com>> wrote:
> 
>     On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
> 
>            What do you have in /etc/env.d/gcc/?  I have this:
> 
>            #ls -l /etc/env.d/gcc/
>            total 16
>            -rw-r--r-- 1 root root  32 2010-02-08 11:53
>         config-i686-pc-linux-gnu
>            -rw-r--r-- 1 root root 235 2009-01-29 12:33
>         i686-pc-linux-gnu-4.1.2
>            -rw-r--r-- 1 root root 235 2009-07-04 09:02
>         i686-pc-linux-gnu-4.3.2
>            -rw-r--r-- 1 root root 235 2010-01-10 12:29
>         i686-pc-linux-gnu-4.3.4
> 
>            Do you still have any version of gcc installed?
> 
>         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.
> 
> 
>     It works, when i am in the folder
>     /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/ and i tried ./gcc, it works.
>     Can you please show me the way  i must put the links in order to
>     work from anywhere(sym links or hard links)? I think it is ln -s
>     //usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/gcc " folder".

This is weird.  I have a small binary /usr/bin/gcc which is obviously just
a stub for starting the version of gcc you select with gcc-config.  The
weird part is that no package claims that file so I don't know how it got
there but the date suggests it was put there by gcc-4.3.4.

$ls -l /usr/bin/gcc*
-rwxr-xr-x 1 root root  9572 2010-01-10 12:29 /usr/bin/gcc   <******* this one
lrwxrwxrwx 1 root root    58 2009-01-29 12:34 /usr/bin/gcc-4.1.2 -> /usr/i686-pc-linux-gnu/gcc-bin/4.1.2/i686-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root    58 2009-07-04 09:03 /usr/bin/gcc-4.3.2 -> /usr/i686-pc-linux-gnu/gcc-bin/4.3.2/i686-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root    58 2010-01-10 12:29 /usr/bin/gcc-4.3.4 -> /usr/i686-pc-linux-gnu/gcc-bin/4.3.4/i686-pc-linux-gnu-gcc
-rwxr-xr-x 1 root root 21711 2010-02-13 14:33 /usr/bin/gcc-config

Do you have a similar /usr/bin/gcc?  It seems to run whatever file
/etc/env.d/gcc/.NATIVE is pointing to, so that symlink must be right for
/usr/bin/gcc to work properly.

Re: [gentoo-user] Re: revdep-rebuild keeps reinstalling binutils

[Konstantinos Bekiaris]

[-- Attachment #1: Type: text/plain, Size: 3899 bytes --]

kostas@Gentoo /usr/bin $ ls -al gcc*

-rwxr-xr-x 1 root root 14504 Jun 17  2008 gcc

lrwxrwxrwx 1 root root    62 Jan 24 06:25 gcc-4.3.4 ->
/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/x86_64-pc-linux-gnu-gcc

-rwxr-xr-x 1 root root 21711 Jan 24 01:46 gcc-config

kostas@Gentoo /usr/bin $



Maybe I have to boot from a live cd, chroot to the hard-disk files, emerge
gcc, reboot and after that emerge -uDN world. Gcc seems to be ok from here,
the problems is somewhere else.




On Sun, Feb 14, 2010 at 1:18 AM, walt <w41ter@gmail.com> wrote:

> Konstantinos Bekiaris wrote:
> >
> >
> > On Tue, Feb 9, 2010 at 8:53 PM, walt <w41ter@gmail.com
>  > <mailto:w41ter@gmail.com>> wrote:
> >
> >     On 02/08/2010 10:27 PM, Konstantinos Bekiaris wrote:
> >
> >            What do you have in /etc/env.d/gcc/?  I have this:
> >
> >            #ls -l /etc/env.d/gcc/
> >            total 16
> >            -rw-r--r-- 1 root root  32 2010-02-08 11:53
> >         config-i686-pc-linux-gnu
> >            -rw-r--r-- 1 root root 235 2009-01-29 12:33
> >         i686-pc-linux-gnu-4.1.2
> >            -rw-r--r-- 1 root root 235 2009-07-04 09:02
> >         i686-pc-linux-gnu-4.3.2
> >            -rw-r--r-- 1 root root 235 2010-01-10 12:29
> >         i686-pc-linux-gnu-4.3.4
> >
> >            Do you still have any version of gcc installed?
> >
> >         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.
> >
> >
> >     It works, when i am in the folder
> >     /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/ and i tried ./gcc, it works.
> >     Can you please show me the way  i must put the links in order to
> >     work from anywhere(sym links or hard links)? I think it is ln -s
> >     //usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4/gcc " folder".
>
> This is weird.  I have a small binary /usr/bin/gcc which is obviously just
> a stub for starting the version of gcc you select with gcc-config.  The
> weird part is that no package claims that file so I don't know how it got
> there but the date suggests it was put there by gcc-4.3.4.
>
> $ls -l /usr/bin/gcc*
> -rwxr-xr-x 1 root root  9572 2010-01-10 12:29 /usr/bin/gcc   <******* this
> one
> lrwxrwxrwx 1 root root    58 2009-01-29 12:34 /usr/bin/gcc-4.1.2 ->
> /usr/i686-pc-linux-gnu/gcc-bin/4.1.2/i686-pc-linux-gnu-gcc
> lrwxrwxrwx 1 root root    58 2009-07-04 09:03 /usr/bin/gcc-4.3.2 ->
> /usr/i686-pc-linux-gnu/gcc-bin/4.3.2/i686-pc-linux-gnu-gcc
> lrwxrwxrwx 1 root root    58 2010-01-10 12:29 /usr/bin/gcc-4.3.4 ->
> /usr/i686-pc-linux-gnu/gcc-bin/4.3.4/i686-pc-linux-gnu-gcc
> -rwxr-xr-x 1 root root 21711 2010-02-13 14:33 /usr/bin/gcc-config
>
> Do you have a similar /usr/bin/gcc?  It seems to run whatever file
> /etc/env.d/gcc/.NATIVE is pointing to, so that symlink must be right for
> /usr/bin/gcc to work properly.
>
>
>


-- 
Greetings, Daemon!

[-- Attachment #2: Type: text/html, Size: 5721 bytes --]