| View previous topic :: View next topic |
| Author |
Message |
rhill
Retired Dev
Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca
|
 Posted: Sat Apr 09, 2005 1:12 am Post subject: HOWTO 'Could not run/locate "i386-pc-linux-gnu-gcc" |
 |
|
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 |
|
 |
david.birch
n00b
Joined: 26 Nov 2004
Posts: 13
|
| Posted: Tue May 31, 2005 1:28 pm Post subject: package cd can cause this too! |
|
|
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 |
|
|
teletoby
n00b
Joined: 04 Jul 2005
Posts: 1
|
| Posted: Mon Jul 04, 2005 11:50 am Post subject: 2005.0 precompiled xorg-x11 |
|
|
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 |
|
|
hex
n00b
Joined: 11 Aug 2003
Posts: 12
Location: Germany
|
| Posted: Sat Aug 13, 2005 8:07 am Post subject: |
|
|
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 |
|
|
PinkPolarTurkey
n00b
Joined: 08 Aug 2004
Posts: 30
|
| Posted: Sat Aug 13, 2005 8:18 am Post subject: |
|
|
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  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 |
|
|
hex
n00b
Joined: 11 Aug 2003
Posts: 12
Location: Germany
|
| Posted: Sat Aug 13, 2005 8:40 am Post subject: |
|
|
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 |
|
|
FluffyArmada
Tux's lil' helper
Joined: 13 Mar 2004
Posts: 107
Location: Dortmund
|
| Posted: Sat Aug 13, 2005 6:00 pm Post subject: They should really note this.... |
|
|
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 |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Mon Sep 12, 2005 6:53 am Post subject: |
|
|
| 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 |
|
|
atifjedi
n00b
Joined: 29 Jan 2004
Posts: 11
|
| Posted: Mon Sep 12, 2005 9:46 am Post subject: |
|
|
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 |
|
|
gheff
n00b
Joined: 03 Feb 2004
Posts: 19
Location: Corryong, NE Victoria, Australia
|
| Posted: Mon Sep 12, 2005 1:37 pm Post subject: |
|
|
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 |
|
|
aim1159
n00b
Joined: 24 Aug 2002
Posts: 60
Location: Saint-Petersburg, Russia
|
| Posted: Tue Sep 13, 2005 4:41 pm Post subject: |
|
|
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 |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Tue Sep 13, 2005 6:07 pm Post subject: |
|
|
| 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 |
|
|
aim1159
n00b
Joined: 24 Aug 2002
Posts: 60
Location: Saint-Petersburg, Russia
|
| Posted: Wed Sep 14, 2005 10:13 am Post subject: |
|
|
| 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 |
|
|
Tarquareion
n00b
Joined: 04 May 2005
Posts: 13
|
| Posted: Thu Sep 15, 2005 1:02 pm Post subject: Re: They should really note this.... |
|
|
| 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 
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... 
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 |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Thu Sep 15, 2005 10:59 pm Post subject: |
|
|
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 |
|
|
UncleOwen
Veteran
Joined: 27 Feb 2003
Posts: 1493
Location: Germany, Hamburg
|
| Posted: Thu Sep 15, 2005 11:04 pm Post subject: |
|
|
| 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 |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Thu Sep 15, 2005 11:21 pm Post subject: |
|
|
| 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 |
|
|
UncleOwen
Veteran
Joined: 27 Feb 2003
Posts: 1493
Location: Germany, Hamburg
|
| Posted: Fri Sep 16, 2005 10:44 am Post subject: |
|
|
| 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 |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Fri Sep 16, 2005 5:04 pm Post subject: |
|
|
| 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 |
|
|
insomniac
Tux's lil' helper
Joined: 25 Jul 2002
Posts: 132
Location: Lund, Sweden
|
| Posted: Mon Oct 31, 2005 6:27 pm Post subject: |
|
|
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 |
|
|
space2
n00b
Joined: 20 Nov 2005
Posts: 13
|
| Posted: Tue Nov 22, 2005 12:52 pm Post subject: |
|
|
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 |
|
|
space2
n00b
Joined: 20 Nov 2005
Posts: 13
|
| Posted: Tue Nov 22, 2005 1:30 pm Post subject: |
|
|
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 |
|
|
asterix404
Apprentice
Joined: 05 Nov 2004
Posts: 213
|
| Posted: Sun Mar 05, 2006 4:44 am Post subject: |
|
|
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 |
|
|
EliasP
Guru
Joined: 06 Dec 2002
Posts: 318
Location: South-West Germany
|
| Posted: Sun Mar 19, 2006 8:22 am Post subject: |
|
|
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 |
|
|
SilveRo
Tux's lil' helper
Joined: 13 Oct 2003
Posts: 147
Location: Milan (Italy)
|
| Posted: Mon Apr 03, 2006 5:47 pm Post subject: |
|
|
| 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 |
|
|
|
Portage & Programming
