Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO 'Could not run/locate "i386-pc-linux-gnu-gcc"
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
rhill
Developer
Developer


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Sat Apr 09, 2005 1:12 am    Post subject: HOWTO 'Could not run/locate "i386-pc-linux-gnu-gcc" Reply with quote

since there are only 20 threads about this, i figured one more wouldn't hurt.

Quote:
gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"


do the following, adjusting for your system setup of course.

Code:

root ~ # gcc-config -l

[1] i686-pc-linux-gnu-3.3.5-20050130   <---  OLD COMPILER #1
[2] i686-pc-linux-gnu-3.3.5-20050130-hardened
[3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp
[5] i686-pc-linux-gnu-3.4.3-20050110   <---  OLD COMPILER #2
[6] i686-pc-linux-gnu-3.4.3-20050110-hardened
[7] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie
[8] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp
[9] i686-pc-linux-gnu-4.0.0-beta20050402 *   <--- NEW COMPILER

root ~ # fix_libtool_files.sh 3.3.5-20050130
                                                              ^------ OLD COMPILER #1
 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/6] Scanning /lib ...
 *   [2/6] Scanning /usr/lib ...
 *     FIXING: /usr/lib/xmms/Input/libmp4.la ...[v]
 *     FIXING: /usr/lib/libid3.la ...[v]
 *     FIXING: /usr/lib/libmng.la ...[v]
 *     FIXING: /usr/lib/libImlib.la ...[v]
 *     FIXING: /usr/lib/libtiff.la ...[v]
 *   [3/6] Scanning /opt/sun-jdk-1.5.0.02/jre/lib ...
 *   [4/6] Scanning /usr/games/lib ...
 *   [5/6] Scanning /usr/i686-pc-linux-gnu/lib ...
 *   [6/6] Scanning /usr/local/lib ...

root ~ # fix_libtool_files.sh 3.4.3-20050110
                                                              ^----- OLD COMPILER #2
 * Scanning libtool files for hardcoded gcc library paths...
(...)

root ~ # fix_libtool_files.sh 3.3.5-20050130 --oldarch i386-pc-linux-gnu
                                                             ^----- OLD COMPILER #1 AGAIN     ^----- ARCH NAMED IN ERROR MSG

root ~ # fix_libtool_files.sh 3.4.3-20050110 --oldarch i386-pc-linux-gnu
                                                             ^----- OLD COMPILER #2 AGAIN     ^----- ARCH NAMED IN ERROR MSG

root ~ # gcc-config -l

[1] i686-pc-linux-gnu-3.3.5-20050130
[2] i686-pc-linux-gnu-3.3.5-20050130-hardened
[3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp
[5] i686-pc-linux-gnu-3.4.3-20050110
[6] i686-pc-linux-gnu-3.4.3-20050110-hardened
[7] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie
[8] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp
[9] i686-pc-linux-gnu-4.0.0-beta20050402 *

root ~ # gcc-config 1    <---- switch to any other compiler

 * Switching to i686-pc-linux-gnu-3.3.5-20050130 compiler ...

root ~ # env-update && source /etc/profile

root ~ # fix_libtool_files.sh 4.0.0-beta20050402
                                                             ^----- NEW COMPILER

root ~ # fix_libtool_files.sh 4.0.0-beta20050402 --oldarch i386-pc-linux-gnu
                                                             ^----- NEW COMPILER                   ^----- ARCH NAMED IN ERROR MSG

root ~ # gcc-config 9    <---- switch back to NEW COMPILER

root ~ # env-update && source /etc/profile


if that doesn't work, try using just the base versions of gcc (3.3.5/3.4.3/etc)

if it STILL doesn't work, try figuring out what package it is that has the broken hardcoded library path and remerge it. you can get hints from the name of the library, what libraries are being linked when it errors on you (look for things starting with "-l" like "-ltiff" or "-lIDL" (that would be libtiff and libIDL respectively). if you have more than one package that you get this error with, see what dependencies they have in common. you can use http://gentoo-portage.com/ to look up reverse dependencies.

fix_libtool_files.sh works - you just have to find the right command to give it.

if all else fails, recompile your toolchain. (glibc, binutils, gcc)
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
david.birch
n00b
n00b


Joined: 26 Nov 2004
Posts: 13

PostPosted: Tue May 31, 2005 1:28 pm    Post subject: package cd can cause this too! Reply with quote

Hi, after many changes to gcc etc, i have discovered that package cd install was the root problem of this =(

in my case - some extensions to ruby (amrita) & xorg (gimp) refused to install, barfing with the

Could not run/locate "i386-pc-linux-gnu-gcc"

message.

anyway, re-compile of most of my system, and now it works...(some of which was done tediously package by package, as occasionaly emerge system & emerge world were breaking...)

hope this helps
Back to top
View user's profile Send private message
teletoby
n00b
n00b


Joined: 04 Jul 2005
Posts: 1

PostPosted: Mon Jul 04, 2005 11:50 am    Post subject: 2005.0 precompiled xorg-x11 Reply with quote

hi,

for the records... i installed gentoo 2005.0 on my laptop and because it is a slow machine i installed precompiled binaries where i could. i used the original make.conf file that came with my stage3 install and did not change USE-flags and CHOST as long as I installed precompiled binaries from the official release.

recompiling xorg-x11 is certainly the cleanest way to solve this problem but on my laptop it is not an option.

here is how i fixed the problem and up to now it worked fine:

- fix_libtool_files.sh 3.3.5 --oldarch i386-pc-linux-gnu
definitely finds some libtool files (mostly in kde) and fixes them.

- search for the #define CcCmd definition in /usr/lib/X11/config/host.def and replace 'i386-pc-linux-gnu' with 'i686-pc-linux-gnu'.

this should fix at least the problems with kde-stuff and standard x11 applications.


teletoby
Back to top
View user's profile Send private message
hex
n00b
n00b


Joined: 11 Aug 2003
Posts: 12
Location: Germany

PostPosted: Sat Aug 13, 2005 8:07 am    Post subject: Reply with quote

Hi,

I got the problem at my fresh 2005.1-install on my server. I installed from stage1 and on "emerge -e system" the problem appeared.
Here is my workaround
Code:
ln -sf /usr/bin/i686-pc-linux-gnu-gcc /usr/bin/i386-pc-linux-gnu-gcc
emerge python
emerge -e system

It's not the cleanest solution, but it worked for me ;)

- hex
_________________
#gentoo@euIRC
Back to top
View user's profile Send private message
PinkPolarTurkey
n00b
n00b


Joined: 08 Aug 2004
Posts: 30

PostPosted: Sat Aug 13, 2005 8:18 am    Post subject: Reply with quote

I had the same problem on an IBM T41 just then, still trying to fix it. After I re-bootstrap it, I'll give your messy idea a go :D I thought about a ln but the original binaries scared me :( I'll back them up anyway. Was this for the python-checksum or something along those lines?
Back to top
View user's profile Send private message
hex
n00b
n00b


Joined: 11 Aug 2003
Posts: 12
Location: Germany

PostPosted: Sat Aug 13, 2005 8:40 am    Post subject: Reply with quote

Yes. This is why you must emerge python before emerging the rest of the system.
Until now, I don't have any problems with this dirty solution ;)

- hex
_________________
#gentoo@euIRC
Back to top
View user's profile Send private message
FluffyArmada
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2004
Posts: 107
Location: Dortmund

PostPosted: Sat Aug 13, 2005 6:00 pm    Post subject: They should really note this.... Reply with quote

I understand it makes gentoo look a little bit flaky... but I really think someone should make a note of this problem in the installation documentation...
So instead of people trying to install gentoo and thinking, "Wow. This sucks.", they can think, "Wow. This sucks, but its a known issue and people are probably working on it as I think..."..

Just my two cents.
_________________
-- fluffyarmada
"Fancy thinking that the beast is something you can hunt and kill."
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3057
Location: Redmond, WA

PostPosted: Mon Sep 12, 2005 6:53 am    Post subject: Reply with quote

hex wrote:
Hi,

I got the problem at my fresh 2005.1-install on my server. I installed from stage1 and on "emerge -e system" the problem appeared.
Here is my workaround
Code:
ln -sf /usr/bin/i686-pc-linux-gnu-gcc /usr/bin/i386-pc-linux-gnu-gcc
emerge python
emerge -e system

It's not the cleanest solution, but it worked for me ;)

- hex


You don't have to do that even. All I did was use gcc-config to choose an i686 gcc version (acutally done automatically for me when I emerged the 3.4.4 version of gcc) and "emerge python --nodeps --oneshot"
Back to top
View user's profile Send private message
atifjedi
n00b
n00b


Joined: 29 Jan 2004
Posts: 11

PostPosted: Mon Sep 12, 2005 9:46 am    Post subject: Reply with quote

Hi all,
I am using gentoo for almost 2 yrs now. I get these problems quite frequently. I am also trying these solutions to work around. why these problems are not addressed properly in the distribution. this really sucks, specially to new users

Atif
Back to top
View user's profile Send private message
gheff
n00b
n00b


Joined: 03 Feb 2004
Posts: 19
Location: Corryong, NE Victoria, Australia

PostPosted: Mon Sep 12, 2005 1:37 pm    Post subject: Reply with quote

Hi All,

Quoting hex...

hex wrote:
Hi,

I got the problem at my fresh 2005.1-install on my server. I installed from stage1 and on "emerge -e system" the problem appeared.
Here is my workaround
Code:
ln -sf /usr/bin/i686-pc-linux-gnu-gcc /usr/bin/i386-pc-linux-gnu-gcc
emerge python
emerge -e system

It's not the cleanest solution, but it worked for me ;)

- hex


I found that this did not work because i686-pc-linux-gnu-gcc binary complained about how it was invoked if it did not reconigned the CHOST arch. So I did this... I wrote a simple "hack" script that fixed the problem...

Code:
damac # cat i386-pc-linux-gnu-gcc
#!/bin/sh
/usr/bin/i686-pc-linux-gnu-gcc "$@"
damac # pwd
/usr/bin
damac #


Don't forget to chmod +x i386-pc-linux-gnu-gcc after you create it.

To make it generic... create the script based on the oldarch it is complaining about not running/locating (in this example i386-pc-linux-gnu-gcc) invoking the newarch CHOST type gcc compiler (i686-pc-linux-gnu-gcc in this example).

Hope this helps!

Greg.
_________________
Life? What is Life? Find it!
Back to top
View user's profile Send private message
aim1159
n00b
n00b


Joined: 24 Aug 2002
Posts: 60
Location: Saint-Petersburg, Russia

PostPosted: Tue Sep 13, 2005 4:41 pm    Post subject: Reply with quote

hmmm... that's all very easy to do, but have someone fill the bugreport? it is very strange to do with the default install of the system, mostly because everything was fine some releases before...


urh?
_________________
/aim
Soft: i386 Ubuntu "Dapper Drake (beta2)"; Linux Kernel 2.6.15
Hard: RoverBook Explorer W200L (Turion64/2Gb RAM/100 Gb HDD/ATI Radeon XPRESS 200M)
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3057
Location: Redmond, WA

PostPosted: Tue Sep 13, 2005 6:07 pm    Post subject: Reply with quote

aim1159 wrote:
hmmm... that's all very easy to do, but have someone fill the bugreport? it is very strange to do with the default install of the system, mostly because everything was fine some releases before...


urh?


That's the thing... this problem has always been there with every release.

The problem is that python was built for i386 then when you rebuild gcc/glibc you have nothing for i386 anymore. Then when you try to do "emerge portage" it tries to call python but python hasn't been rebuilt and refers to the non-existent i386 compiler.

And this didn't normally come up before because bootstrapping used to rebuild python.

edit:
But even in the old releases if you explicitly upgraded gcc and glibc, didn't re-install python, and tried to do "emerge portage" you'd have problems.
Back to top
View user's profile Send private message
aim1159
n00b
n00b


Joined: 24 Aug 2002
Posts: 60
Location: Saint-Petersburg, Russia

PostPosted: Wed Sep 14, 2005 10:13 am    Post subject: Reply with quote

slycordinator wrote:
aim1159 wrote:
hmmm... that's all very easy to do, but have someone fill the bugreport? it is very strange to do with the default install of the system, mostly because everything was fine some releases before...


urh?


That's the thing... this problem has always been there with every release.


hmm... I never faced with this previously, that's why I was very upset with this.
_________________
/aim
Soft: i386 Ubuntu "Dapper Drake (beta2)"; Linux Kernel 2.6.15
Hard: RoverBook Explorer W200L (Turion64/2Gb RAM/100 Gb HDD/ATI Radeon XPRESS 200M)
Back to top
View user's profile Send private message
Tarquareion
n00b
n00b


Joined: 04 May 2005
Posts: 13

PostPosted: Thu Sep 15, 2005 1:02 pm    Post subject: Re: They should really note this.... Reply with quote

FluffyArmada wrote:
I understand it makes gentoo look a little bit flaky... but I really think someone should make a note of this problem in the installation documentation...
So instead of people trying to install gentoo and thinking, "Wow. This sucks.", they can think, "Wow. This sucks, but its a known issue and people are probably working on it as I think..."..


I couldn't agree more :roll:

If I had known this beforehand, I could have done the trick before emerge -e system, which would have saved me about six hours of compiling... :x

and btw, I've never had this problem before either.
_________________
The fellow who thinks he knows it all is especially annoying to those of us who do.

Registered Linux User #400299
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3057
Location: Redmond, WA

PostPosted: Thu Sep 15, 2005 10:59 pm    Post subject: Reply with quote

Just so you guys know...

The only reason this happens is because you changed the CHOST in make.conf. And I just found out that really changing the CHOST is completely unneeded.

So if you leave the CHOST line as you originally had when you unpacked the stage tarball you'll avoid this problem altogether.

Hopefully someone will edit the install guide to indicate this.
Back to top
View user's profile Send private message
UncleOwen
Veteran
Veteran


Joined: 27 Feb 2003
Posts: 1493
Location: Germany, Hamburg

PostPosted: Thu Sep 15, 2005 11:04 pm    Post subject: Reply with quote

slycordinator wrote:
The only reason this happens is because you changed the CHOST in make.conf.


Well, that's the reason one usually does a stage one. But than again... there are i686 stage three tarballs, so at least on newer x86 systems there is no need to to this.
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3057
Location: Redmond, WA

PostPosted: Thu Sep 15, 2005 11:21 pm    Post subject: Reply with quote

UncleOwen wrote:


Well, that's the reason one usually does a stage one. But than again... there are i686 stage three tarballs, so at least on newer x86 systems there is no need to to this.


Not true at all. The reason you do a stage1 is to make a system fully optimized for your system.

Changing CHOST actually does absolutely nothing but make gcc installed to a different directory.

edit:
Here's a quote from a dev when I bugged the (Could not run/locate "i386-pc-linux-gnu-gcc") issue -

Quote:
There's no need to change CHOST besides cosmetics.


And another dev gave a similar comment in a related bug report:

Quote:
Changing CHOST has no effect other than changing the location of the toolchain files.


Hope that helps
Back to top
View user's profile Send private message
UncleOwen
Veteran
Veteran


Joined: 27 Feb 2003
Posts: 1493
Location: Germany, Hamburg

PostPosted: Fri Sep 16, 2005 10:44 am    Post subject: Reply with quote

slycordinator wrote:
UncleOwen wrote:


Well, that's the reason one usually does a stage one. But than again... there are i686 stage three tarballs, so at least on newer x86 systems there is no need to to this.


Not true at all. The reason you do a stage1 is to make a system fully optimized for your system.


Er, no. That's what a stage2 is for. emerge -e system _does_ recompile everything, so everything is optimized.
Stage1 gives you the "benefit" (I'm not arguing that it actually is one) of being able to change CHOST. See section 5e of the handbook.
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3057
Location: Redmond, WA

PostPosted: Fri Sep 16, 2005 5:04 pm    Post subject: Reply with quote

UncleOwen wrote:


Er, no. That's what a stage2 is for. emerge -e system _does_ recompile everything, so everything is optimized.
Stage1 gives you the "benefit" (I'm not arguing that it actually is one) of being able to change CHOST. See section 5e of the handbook.


Sorry for the confusion. I didn't notice that the regular install guide was changed to do "emerge -e system". It used to be that at stage2 you did "emerge system" rather than "emerge -e system" and the bootstrap script was much bigger, installing much more of the system.

Though honestly if you're doing "emerge -e system" you should be able to change CHOST with no problems (except that there is a bug that python-fchksum right now is installed before python but they've got it fixed waiting for testing).

edit:
So the reason I said that stage1 was for optimising everything is because stage1 installs used to act like that and stage2 installs used to work differently than now
Back to top
View user's profile Send private message
insomniac
Tux's lil' helper
Tux's lil' helper


Joined: 25 Jul 2002
Posts: 132
Location: Lund, Sweden

PostPosted: Mon Oct 31, 2005 6:27 pm    Post subject: Reply with quote

I got the same error (could not locate...) after changing mobo+cpu, changing chost and recompiling 'emerge -e world'. Emerge borked while emerging groff. First I tried the tricks with fix_libtool_files.sh but to no avail. Even symlinked /usr/i386... to /usr/i686 but that didn't help either.

Finally I poked around (I wouldn't call it "analyze" because I don't know anything about programming) in the error message and saw that there were references to /x11/ right before the error. So I recompiled xorg-x11 and lo and behold, after that, groff compiled cleanly.
_________________
My next computer is also a Gentoo computer
Back to top
View user's profile Send private message
space2
n00b
n00b


Joined: 20 Nov 2005
Posts: 13

PostPosted: Tue Nov 22, 2005 12:52 pm    Post subject: Reply with quote

Hi!

I have the same problem, I had it witth different packages already, but fix_libtool_files.sh fixed almost each of them... except Xaw3d.

I'm trying to emerge it, and I get:

--------8<--------
gccmakedep -- -I. -I/usr/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DHAS_WCHAR_H -DHAS_WCTYPE_H -DNO_WIDEC_H -DARROW_SCROLLBAR -DUSEGRAY -- AllWidgets.c AsciiSink.c AsciiSrc.c AsciiText.c Box.c Command.c Dialog.c Form.c Grip.c Label.c Layout.c List.c MenuButton.c MultiSrc.c MultiSink.c Paned.c Panner.c Porthole.c Repeater.c Scrollbar.c Simple.c SimpleMenu.c Sme.c SmeBSB.c SmeLine.c SmeThreeD.c StripChart.c Text.c TextSink.c TextSrc.c TextAction.c TextPop.c TextTr.c ThreeD.c Toggle.c Tree.c Vendor.c Viewport.c XawIm.c XawInit.c XawI18n.c sharedlib.c laygram.c laylex.c
gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"
rm -f AllWidgets.o unshared/AllWidgets.o
i386-pc-linux-gnu-gcc -c -I. -I/usr/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DHAS_WCHAR_H -DHAS_WCTYPE_H -DNO_WIDEC_H -DARROW_SCROLLBAR -DUSEGRAY -O2 -fno-strength-reduce -fno-strict-aliasing AllWidgets.c -o unshared/AllWidgets.o
gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"
make: *** [AllWidgets.o] Error 1

!!! ERROR: x11-libs/Xaw3d-1.5-r1 failed.
!!! Function src_compile, Line 59, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.
--------8<--------

I run the fix_libtool_files.sh, but no use :-(

Any hints about what could be the problem and how could I solve it?

Thanks in advance!
Back to top
View user's profile Send private message
space2
n00b
n00b


Joined: 20 Nov 2005
Posts: 13

PostPosted: Tue Nov 22, 2005 1:30 pm    Post subject: Reply with quote

Ok, fixed conform https://forums.gentoo.org/viewtopic-t-318790.html



teletoby wrote:


- fix_libtool_files.sh 3.3.5 --oldarch i386-pc-linux-gnu
definitely finds some libtool files (mostly in kde) and fixes them.

- search for the #define CcCmd definition in /usr/lib/X11/config/host.def and replace 'i386-pc-linux-gnu' with 'i686-pc-linux-gnu'.

this should fix at least the problems with kde-stuff and standard x11 applications.


teletoby
Back to top
View user's profile Send private message
asterix404
Apprentice
Apprentice


Joined: 05 Nov 2004
Posts: 213

PostPosted: Sun Mar 05, 2006 4:44 am    Post subject: Reply with quote

Yea I really gotta say... I have used stage 2 for about 2 years... and I have used stage 1 on my laptop and when I had to reinstall... essentially from what I have gathered.... this is the amusing bit...
once you have everything the way you want it...

emerge glibc && emerge binutils && emerge gcc
emerge python
emerge -e system
emerge world

essentially is a stage 1, this causes me much joy... yet the fact that I would have had to do this normally... I don't exactly like. Why on earth did they stop supporting stage 1 installs? I loved them... it would take 10h and everything would more or less work...
Back to top
View user's profile Send private message
EliasP
Guru
Guru


Joined: 06 Dec 2002
Posts: 317
Location: South-West Germany

PostPosted: Sun Mar 19, 2006 8:22 am    Post subject: Reply with quote

The cleanest and fastest solution, that worked for me, is this:

Find out, which packages need to be re-emerged:
Code:

grep i386-pc-linux-gnu-gcc /var/db/pkg/ -r|cut -d\/ -f5-6

Just let them automatically re-emerge:
Code:

for package in $(grep i386-pc-linux-gnu-gcc /var/db/pkg/ -r|cut -d\/ -f5-6); do emerge =${package}; done


Hope it helps.
Back to top
View user's profile Send private message
SilveRo
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2003
Posts: 147
Location: Milan (Italy)

PostPosted: Mon Apr 03, 2006 5:47 pm    Post subject: Reply with quote

EliasP wrote:
The cleanest and fastest solution, that worked for me, is this:

Find out, which packages need to be re-emerged:
Code:

grep i386-pc-linux-gnu-gcc /var/db/pkg/ -r|cut -d\/ -f5-6

Just let them automatically re-emerge:
Code:

for package in $(grep i386-pc-linux-gnu-gcc /var/db/pkg/ -r|cut -d\/ -f5-6); do emerge =${package}; done


Hope it helps.


Your script is good! It finds some packages, and a slightly modified one, with i386-pc-linux-gnu (removing the -gcc) finds even more. It may be connected to the fact that I used the wrong stage3 (i386 instead of i686)....

Anyhow, here is what I am using to solve my "wrong stage3 problem (i386 instead of i686, that is in my make.conf)". Let me know if u think it's correct....

Code:
grep i386-pc-linux-gnu /var/db/pkg/*/*/CHOST -R|cut -d\/ -f5-6
for package in $(grep i386-pc-linux-gnu /var/db/pkg/*/*/CHOST -R|cut -d\/ -f5-6); do emerge =${package}; done

_________________
Think Gray
(things aren't all black or all white)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum