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.