oops, how does one re-install gcc?

Jeremy Byron rjjbyron at shaw.ca
Wed Oct 19 17:37:42 PDT 2005

Lennon Cook wrote:
> Tushar Teredesai wrote:
>>Not true. It is a *myth* that has propogated thru these lists so many
>>times that it *sounds* true. If it were true, gentoo users would need
>>to reinstall their OS every time a toolchain package was updated.
> Gentoo users are generally told that they should to 'emerge -e' (which
> recompiles everything currently installed) following a glibc upgrade.
> --
> Lennon Victor Cook

Thanks, Lennon, you just made my point (more or less).

I don't think it's a myth at all.  Programs can fail silently when a 
dependency is missing and potentially cause all manner of hard to trace 

Take firefox for example, which segfaults without any given reason when 
the fonts aren't setup correctly.  This leads to questions like, why 
does my firefox not work when I didn't use optimizations and it built 

More specific to upgrading toolchain programs, look at the ATI binary 
drivers; they will initialize 3D and say everything is good to go, but 
you will not have 3D acceleration if libstdc++.so.5 is missing.  In 
fact, it won't give any output whatsoever that it failed, so unless 
you're doing something specific to 3D you will never know that your 
driver is broken.  Upgrading to gcc-3.4.x in this case (by removing 
gcc-3.3.x) would therefore be problematic if done naively.

I'm sure other programs behave in the same way, so unless you know which 
programs may be broken, it's best to rebuild all installed programs. 
Hence why I said that you may as well rebuild LFS if you're going to be 
altering the toolchain packages.

Tushar, you say the toolchain programs are backwards compatible but that 
library names can be changed and so they must be preserved.  You aren't 
completely removing the old version in this case, you are creating a 
merged mess of installations.  Furthermore, unless you have a list of 
libraries that are changed or a list of altered symbols within libraries 
that have had their names preserved cross referenced with a list of 
installed programs that will be affected, it is a bad idea to replace 
your toolchain programs.  I believe I said 'bad idea' not 'cannot' when 
I responded to Doug and even qualified it with a 'same version (same 
symbols/interface if you're a more technically informed reader)' when 
pointing him to how BLFS updates gcc.

Of course, if you are a technically informed reader, you already know 
whether or not it is safe to replace your toolchain packages with a 
given version difference and what packages will be affected and so you 
can feel free to ignore the 'bad idea'/'should never remove' warnings, 
knowing full well what you are doing.  Unfortunately, many people who 
need to reference the BLFS book do not come close to fitting into this 
category; in fact, I'd be surprised if any but most of the devs do.


More information about the lfs-support mailing list