Automatically update GCC to a later release without upgrading distribution

Question

My understanding is that C++11 support in G++ 4.7.2 wasn't great (it gives me a warning everytime I try to compile my C++ code, presumably there are good reasons for these warnings), so thought I would try to update to something newer.

I don't have a lot of download quota so I really want to limit the amount I download, so I definitely don't want to upgrade Debian stable (Wheezy) or upgrade build-essentials unless I really need to.

Is there a simple command I can use to apt-get the latest GCC release (or any with full C++11 support) without doing anything screwy to my aptitude repos?

I would prefer it if the answer came in the form of a command I can run that will overwrite any existing install, as I'm still struggling with the whole Linux install process.

Solution 1

The package management gives you a set of packages that "belong together". Trying to trick it to install a new set of software that doesn't belong in your distro is likely to "not work out great". What typically happens is that you get a huge daisy-chain of follow-on packages that you also need to upgrade (e.g. "gcc needs a new glibc, new glibc needs new binutils, new binutils breaks your gdb, so you need to update that", etc).

I find it a better solution to retain the existing installed tools where they are, and then build my own version of gcc, llvm+clang, gdb, lldb or whatever it is I feel I need a later version of. Typically, this works without trouble, because it installs in /usr/local/{bin,lib,include,...}, where the distros tools install in /usr/{bin,lib,include,...} - so if you ever need to use the older ones (and sometimes that turns out to be the case, e.g. you got a newer gcc that unfortunately isn't capable of compiling project A - or even itself) - you use use /usr/bin/gcc or edit your $PATH to not use /usr/local.

I have a Fedora-16 install, but I use gcc 4.8.2 (the latest as of end of March) and clang 3.5 - the default compilers that the system comes with are gcc 4.6.3 and clang 2.9. Clang 3.5 requires a C++11 compatible compiler, so 4.7 or 4.8 is required for that project. It works just fine. (but the new gcc and clang breaks older gdb such that symbols don't work as expected, so I either need to rebuild gdb or upgrade it).

Solution 2

The correct way of doing this is using backports. See How can I install more recent versions of software than what Debian provides? for background. Unfortunately, this is not "automagical", whatever that means.

I'll outline the procedure below. The question does not specify the gcc version, but 4.9 was just released, so I'll restrict myself to describing how to backport that. Each backport is different and has different issues; there is no general recipe.

1) Download the gcc 4.9 sources in some subdirectory, say gcc-4.9.

cd gcc-4.9
apt-get source gcc-4.9

2) Then

cd gcc-4.9-4.9.0/debian

3) Then put the debian/ directory under version control. I use Mercurial. This is an optional step, but is useful if something goes wrong.

4) Clone this Mercurial repository containing a patch against the Debian packaging files repository. You can clone it in the debian/ directory. I.e.

gcc-4.9/gcc-4.9-4.9.0/debian$ hg clone https://bitbucket.org/faheem/gcc-4.9-debian-mq
gcc-4.9/gcc-4.9-4.9.0/debian$ patch -p1 < gcc-4.9-debian-mq/debian

patching file control
patching file rules.defs
patching file source/format

4) Now you can attempt a build. You'll need a few packages installed, like build-essential, fakeroot and devscripts.

debuild -uc -us

This will probably fail if you don't have the necessary build dependencies. So, install them; debuild will tell you what is missing. With the patch you should be able to successfully resolve all dependencies on wheezy.

When this process concludes, you will have gcc debs at the top level of your directory, gcc-4.9, which should be installable on Wheezy. Note: I have not checked this at time of writing - see below.

NOTES: This patch may not continue to work for further updates of gcc-4.9. For reference, here is the version I am patching against. This is the first Debian package following the gcc 4.9 release on 2014-04-22.

$ apt-cache policy gcc-4.9
gcc-4.9:
  Installed: (none)
  Candidate: 4.9.0-1
  Version table:
     4.9.0-1 0
         50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages

Therefore, I'm including some notes about how the patch was generated, so others can do this themselves. Please read through this. In particular, note (6) (Multiarch) may concern you even if you are not planning to make your own patch.

1) First, the build dependencies are for unstable, and are unnecessarily restrictive. The first thing is to weaken the restrictions so that the build dependencies are satisfied on wheezy. So, first try

debuild -uc -us

debuild will complain about build dependencies not being installed. Even after they are installed, debuild will complain about the versions not being sufficiently recent. So, the simplest thing to do is to remove the version numbers mentioned.

Examples of this are the various binutils, libcloog-isl-dev, and libmpc-dev.

So, for example change

libmpc-dev (>= 1.0),

to

libmpc-dev,

in the Build-Depends: line at the top of the debian/control file, which contains information about the build dependencies and the binary packages. Once this is done for all offending packages, and you have installed the necessary build packages, the Debian build system will run.

2) Another thing you need to do is remove support for x32. This is not available for Wheezy. For example, the libc6-dev-x32 package does not exist on Wheezy. This is done by going into debian/rules.defs and removing all mention of x32. This file is used by the build file debian/rules.

3) You also want to change debian/source/format. This is source format 1, for some reason. Change this to version 3.0 (quilt). So, change the contents of this file from 1.0 to 3.0 (quilt).

This is only strictly necessary if you are putting the debian/ directory under version control. For reasons I won't go into here, format 1 makes the build fail if debian/ is under version control.

4) gcc runs an extensive, and I mean extensive, test suite during this build. If you don't want it to do this, then it can be disabled by changing the following lines in rules.defs (which appears below # if you don't want to run the gcc testsuite, uncomment the next line)

from

#with_check := disabled by hand

to

with_check := disabled by hand

I have disabled the test suite in my patch.

5) Immediately after the Debian build system starts running, the control file will be replaced by an autogenerated file using control.m4. However, it is still necessary to modify control, because otherwise the build system will refuse to proceed. It is possible to force it, but this is generally not advisable.

6) Multiarch has the annoying feature that if you update a package, any other architecture installed needs to stay at the same version. I'm running amd64, and this affects me because I'm running i386 packages for my Skype installation. So, if you are running amd64, check and see if you have the same amd64 and i386 gcc packages installed. In particular, the libgcc1 package will be upgraded if you install 4.9. This is harmless.

In any case, at time of writing I have not generated i386 debs, so have not been able to check a gcc 4.9 amd64 wheezy installation.

UPDATE: Finally got around to building i386 debs for gcc 4.9 (in an i386 chroot using schroot (see How do I run 32-bit programs on a 64-bit Debian/Ubuntu?)), and installed those in tandem with the amd64 ones, because of the aforementioned multilib constraint. I'm still testing, but both g++ 4.7 and g++-4.9 compile the code I tested it with. The installation of gcc 4.9 debs isn't completely straightforward, because some of the common libraries for 4.7 and 4.9 need to be upgraded too, like libstdc++6.

I'd be interested in hearing reports from other people about this. If anyone needs assistance adjusting the patch for later versions/releases of gcc 4.9, let me know by commenting here.

Solution 3

I'm afraid is not possible, or at very least, do not worth it. You can do the following:

• Set up a chrooted environment with the newer g++, coming from the repositories. debootstrap should help you with this.
  • Advantages: your installation is not touched. It can aslo be automated.
  • Disadvantages: correctly setting up a chrooted environment sometimes is not trivial. Time.
• Building the packages yourself (backporting)
  • Advantages: high personalization. No need to waste hardisk space
  • Disadvantages: You need to build it again each time, so it's not automatic. The probabilities that your environment gets broken is higher.
• Using a virtual machine:
  • Advantages/disadvantages: same as the chrooted solution, just that both systems are completely separated from the kernel.

Comments

[Admin]

Possible dupe of unix.stackexchange.com/q/36388/4671 from a couple of years ago.

[quant]

so if I add to my sources.list and then remove it again after install, is wheezy going to think my 4.9 install is outdated and try to rewrite it with 4.7 when I update stuff?

[quant]

Also, what exactly should I add to sources.list and what command will I run to update only GCC (apt-get install?).

[Shadur]

Mixing unstable and stable sources is a terrible idea. Look for backports or upgrade to sid all the way -- and your question suggests that sid almost certainly isn't for you.

[Alen Milakovic]

I'm tempted to downvote this, but won't. For the record, this will not work well, as Shadur says. You'll be forced to pull in the C library and tons of other stuff from unstable and it will create problems. gcc is non-trivial to backport, and the only backport I've ever heard of (of gcc 4.7 to squeeze) I made myself.

[Ludwig Schulze]

I think there should be another solution, but I can't think about it right now.

[quant]

Thanks Braiam, I think I'll just stick with GCC 4.7 and hope I don't run into any problems!

[Shadur]

Still not terribly optimal, and I really recommend that you install the source-built gcc in a different path (/usr/local/ is a good call for this), but given the constraints you're under probably the best you'll get.

[jgmjgm]

I am confused, isn't backporting still dependent on a chroot or something like it? In theory there should be another solution importing settings from the target distro (all the defaults) and running GCC with lots of path configurations (such as compile only prefix to look for headers and libraries in the chroot but not to apply the prefix on execution). In practice, I can't find something like that and it seems difficult to set up. It would be a form of crosscompiling.

[Ludwig Schulze]

@jgmjgm no, backporting is just building the new thing using the old tools. Instead of having everything in your toolchain being cutting edge or near it, you could technically build whatever you want with your existing toolchain without changing a thing. That of course opens up to potential incompatibilities that upstream didn't through about (X needs Y feature, but Y feature is only present in a.b.c or later versions of the libraries/compiler which upstream forgot to mention).