| View previous topic :: View next topic |
| Author |
Message |
Herring42
Guru
Joined: 10 Mar 2004
Posts: 373
Location: Buckinghamshire
|
 Posted: Fri Jul 26, 2013 3:08 pm Post subject: |
 |
|
gcc-4.6.3 appears to be broken. I've just upgraded, and it's gone bang too 
_________________
"The problem with quotes on the internet is that it is difficult
to determine whether or not they are genuine." -- Abraham Lincoln |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54640
Location: 56N 3W
|
| Posted: Fri Jul 26, 2013 10:31 pm Post subject: |
|
|
NeddySeagoons Rough Guide to Fixing A Badly Broken Toolchain and other emerge -C Oops
Your are reading this because something is badly broken as a result of emerge --depclean, or emerge -C removing soemthing you really wish it hadn't.
A fairly typical case is an old but active gcc being removed by --depclean leaving a perfectly good but not yet active gcc in its place.
This guide is not for you - you only need to fix your issue.
If you are still reading you need a binary of something to fix the problem. You need a trusted BINHOST, there are several I would trust.
Or you need your own binary ... do you have in make.conf, if you do then you may have your own binary already.
Portage may even install it for you depending on what you did. Look through the packages you have and try | Code: | | emerge -K =<package>-<version> |
Emerge may be so badly broken it can't deal with binary packages even.
The next install method is to use | Code: | | tar xpf /path/to/binary/tarball -C / |
which will unpack the binary package, just as if it was a single package stage3 file.
If the tarball was made by portage, you will get a warning about extra garbage at end of file ignored. Thats because tar does not know about the extra portage specific information at the end of the tarball.
Now what if you can't get a trusted binary package?
What if your box won't even boot, say you managed to run Don't do that just to test this post.
You can still fix it without outside help and without reinstalling.
In summary, the method involves unpacking a stage3 tarball to a directory, borrowing your /usr/portage from the broken install, copying your /etc/portage/* from the broken install, setting up the new install to save binaries, chrooting into the stage3-in-a-dir and either using quickpkg to package things that already exist in the stage3 or emerge to build them for you, saving the binary packages as it goes.
Unpacking a stage3 to your normal root will destroy your install.
Boot Linux somehow. If you own box boots good, if not, System Rescue CD is a good choice.
Mount your filesystems just like you did for the install, not forgetting /proc and /dev (this is done if your system booted)
Make a directory called repair, somewhere you have a few Gb of free space. You will remove this later.
Lets use /home/repair (this will be /mnt/gentoo/home/repair if you needed to boot with a CD)
cd booted users need to prepend /mnt/gentoo/ everywhere below.
Fetch a stage3 tarball and untar it to /home/repair Do not fetch a portage snapshot
mount /proc and /dev/ to /home/repair/dev /home/repair/proc, almost as the handbook says.
Copy over /etc/resolv.conf into the budding /home/repair chroot. You may need networking.
bind mount your real /usr/portage from the broken install to /home/repair/usr/portage
Copy over /etc/portage to /home/repair
Follow the handbook chroot steps to chroot into /home/repair
Edit make.conf to add buildpkg to FEATURES.
Check its there with | Code: | | emerge --info | grep FEATURES |
Do not emerge --sync until the repair is complete and tested. Its important the working 'repair system' matches the install you want to fix.
Whenever you build a package now, a binary of it will be saved to /usr/portage/packages.
Disk wise, due to the bind mount using /usr/portage, its the same place inside and outside the chroot, so packages will be available outside the chroot later.
If a package you need is already in the stage3 at the right version, you may then
However, it may not match your use flags as you didn't build it.
Make the packages you need, then outside the chroot, use one of the methods outlined above to install them. emerge -K is preferred.
Once your system is working again, you can remove /home/repair.
If you don't make enough at the first attempt then /home/repair will still be there for you to come back to. Its only a gentoo chroot in a dir.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
rajat.pandita
n00b
Joined: 24 May 2013
Posts: 10
|
| Posted: Mon Nov 10, 2014 7:25 pm Post subject: neiras's suggestion fixed my issue |
|
|
I faced this issue when I did a system upgrade and gcc got updated.
So I ran
gcc-config -l
then gcc-config f x86_64-pc-linux-gnu-4.8.3
followed by
source /etc/profile
Doing this fixed the issue for me. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Nov 11, 2014 6:50 am Post subject: |
|
|
| Cheers Neddy; saved off as "Recover from a snafu". |
|
| Back to top |
|
|
Al-Caveman
n00b
Joined: 21 Sep 2014
Posts: 39
|
| Posted: Thu Aug 27, 2015 11:38 pm Post subject: |
|
|
| ebrostig wrote: | | port001 wrote: | sure 
I had exported my CFLAGS wrong somehow.. you need to make sure its the correct syntax
| Code: | | export CFLAGS="blah blah" |
|
Thank you!
Now others who see the same issue and searches the forums, will be able to fix it themselves.
Erik |
Thank you for pushing this. It helped me in late 2015! |
|
| Back to top |
|
|
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Sun Jul 31, 2016 8:45 pm Post subject: |
|
|
Ran into this issue today, upgrading a machine that had not seen any updates since may last year. Luckily I did have some binaries available to get me started, but then the dreaded error from this thread popped up. I tried just about anything without the slightest bit of result and then one of the packages I tried to install told me something different: it could not execute 'as'. So I found that 'as' is in fact a symlink to a symlink to a symlink to the actual program in a version dependent folder of the binutils package. And that folder did not exist.
So if you run into this issue, definitely do run `eselect binutils list` and verify that you have a working link. |
|
| Back to top |
|
|
k9dog
Tux's lil' helper
Joined: 22 Jun 2009
Posts: 103
Location: Denmark
|
| Posted: Thu Jan 18, 2018 11:17 am Post subject: |
|
|
| rjenks wrote: |
3) edit /etc/env.d |
Had to reinstall most of the base system. After that gcc wouldn't compile gcc or anything. I restored files from a backup. For some reason I ended up with old config files and a new gcc.
gcc stopped compiling saying it couldn't compile executables. The advice from Rob led me to a file where everything was set up for gcc 6.2. According to my system gcc 6.4 was installed. Editing and renaming files in /etc/env.d/gcc did the trick.
I know I need to do a emerge @system && emerge @world in the end, but this one got me started. Thanks Rob. No idea why system failed (Headless computer with no cd drive so had to work a bit here to get started. Hope ssh stop throwing me off while compiling gcc and dtach (after that I'll do this in background anyway).
--
Addendum: Turned out I needed to set my xfce4 terminal to unicode->utf8. After that it stopped throwing me off. Only eselect had things set to utf 8. So remember to match terminal encoding with server encoding. Even on same machine. |
|
| Back to top |
|
|
|
|
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
|
|
Portage & Programming
