so for the osdev tutorial, it recommended upgrading to 4.8, which is the latest major release. since i was on 4.6, i thought that was a good idea. wanting to follow the tutorial, i recompiled the latest binutils from source then bootstrapped 4.8 from source. i can just use the one i built from source, but I would like to update the one the system came with to 4.8. i dont feel comfortable enough with bootstrapping yet to do it that way, so is there a more surefire way to update the system g++ compiler?
Generally it is not a good idea to change a system default if other components of the system depend on it and the new might not be backward compatible. (This is more of an issue with Python, SQL, ..., but libstdc++ is a central component.)
Additionally, if your base setup is via some package management, then you do not want to replace/overwrite with unmanaged content. Pack up (or find a prepacked gcc-4.8) and let the manager do update (or side install).
Generally it is not a good idea to change a system default if other components of the system depend on it and the new might not be backward compatible.
so glad i asked before doing it
Additionally, if your base setup is via some package management, then you do not want to replace/overwrite with unmanaged content. Pack up (or find a prepacked gcc-4.8) and let the manager do update (or side install).
i am completely updated with package manager and sudo apt-get update
i am completely updated with package manager and sudo apt-get update
Does any of your repositories offer GCC-4.8 for 12.04?
RedHat (packages are not compatible with Ubuntu) has GCC-4.4.7 on its RHEL-6 and is likely do so as long as RHEL-6 is supported, i.e. until 2020. They have come up with a side product though: Developer Toolset. That does install on the side -- not replacing the system default -- and includes now GCC-4.8.1 -based toolchain. In order to use it one essentially updates environment variables (like PATH) to find first the new versions. You do it only in the shell, where you do use them, not on system default configuration.
The RH's environment modifying utility is different from "environment modules" package, which HPC clusters have used for over a decade for exactly the same purpose: multiple versions of applications are installed, but not on path by default, so the user can selectively enable them as needed. (Version X of foo might compute so differently than version Y that repeating scientific experiments requires the use of the old version.)
Then there is the "alternatives". A tool that updates symlinks on default path so that specific version is found (say open source java vs. Oracle java). Yet another (somewhat established) system on how to choose from simultaneously installed alternatives.
I followed the instructions in this post, repeating the proceedure for g++ as well as gcc, which adds the toolset as an alternative (rather than upgrading the existing toolset) if I understand it correctly.