0

I am puzzled. There is seemingly no newer Debian image for Raspberry Pi than the current stable version 12 (bookworm). I have downloaded and installed it just when it went out without issues, I remember. Link to all tested images here. My Pi's HW is 4 (8GB). Just to be clear, I am all Ok with Debian's aim to be rock-stable. Just one thing, if I may poke.


I wonder if it is possible to build an up-to-date version of the g++ (14) on my arm64 Raspberry Pi running Debian 12? (Today, I somewhat needed it, but found out, an older g++-12 available only, it caused me only minor trouble this time.)

And if yes, how would I proceed exactly? I have no clue.


Here is what g++ versions I found available on Linux Mint 22 (based on Ubuntu Noble), i.e. version 10+:

$ apt-cache policy g++-1[0-9] | grep -A 2 '^g++-1'

g++-10:
  Installed: (none)
  Candidate: 10.5.0-4ubuntu2
--
g++-11:
  Installed: (none)
  Candidate: 11.4.0-9ubuntu1
--
g++-12:
  Installed: 12.3.0-17ubuntu1
  Candidate: 12.3.0-17ubuntu1
--
g++-13:
  Installed: 13.3.0-6ubuntu2~24.04
  Candidate: 13.3.0-6ubuntu2~24.04
--
g++-14:
  Installed: 14.2.0-4ubuntu2~24.04
  Candidate: 14.2.0-4ubuntu2~24.04

For reference, here are currently available versions on Pi's Debian 12, i.e. versions 10+, as above:

$ apt-cache policy g++-1[0-9] | grep -A 2 '^g++-1'

g++-10:
  Installed: (none)
  Candidate: (none)
--
g++-11:
  Installed: (none)
  Candidate: 11.3.0-12
--
g++-12:
  Installed: 12.2.0-14
  Candidate: 12.2.0-14
--
g++-13:
  Installed: (none)
  Candidate: (none)

Nope, no sign of g++-14, not even g++-13 available (yet). So, my question above stands. Thank you in advance.

1 Answer 1

2

Warning

@StephenKitt points out that the below is a dangerous operation, as you can end up with a broken system (the VM I tried this on is fine, but that wasn't an arm64 VM nor had any graphical frontend installed).

Your alternative is to get the .dsc file from packages.debian.org's trixie gcc 14, and then build that using dpkg-buildpackage. The instructions for GCC12 on Ubuntu 20.04 I wrote in this answer would solve your issue as well, but would require compiling from source.

Main text

Debian can let you set up "mixed" package sources, where you only pull in packages from the "newer" distro release when explicitly asked to/strictly necessary.

For that, you'd

  1. add a trixie (current testing release of debian) repo
  2. tell apt that it shouldn't use that by default
  3. explicitly install gcc from that repo

1. add a trixie (current testing release of debian) repo

copy the current repo specification

sudo cp /etc/apt/sources.list.d/debian.sources /etc/apt/sources.list.d/triixie.sources

and modify pixie.sources to only list trixie; it should be, afterwards:

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

2. tell apt that it shouldn't use that by default

create a file nvim /etc/apt/preferences.d/99debian-trixie, containing:

Package: *
Pin: release a=testing
Pin-Priority: 100

Test that this did work:

apt update
apt-cache policy
## This should now list the new trixie repository, at priority 100,
## and the default bullseye repo should still be at priority 500
apt-cache policy gcc
## Should now list GCC 14 from trixie as low-priority alternative to
## the default gcc.

3. explicitly install gcc from that repo

(and while we're at it, the usual build tools also in their more modern trixie version)

apt install -t trixie gcc g++ gdb cmake clang-format
11
  • Wow, so it's possible even without compiling! I will try that up once I have a little extra time. Thank you! Commented Dec 19, 2024 at 21:19
  • the alternative is using dpkg-buildpackage to build the gcc (14) package from trixie on bullseye with debian tooling itself. Though, if doing that, you can probably also just set up an schroot on a beefy x86_64 "compile machine" (assuming you have that instead of a beefy arm64 machine) and use sbuild --host=arm64 … to cross-build the packages for the Raspberry Pi. The machine compiling source code doesn't have to have the same CPU as the machine running the result! Commented Dec 19, 2024 at 21:23
  • Given GCC’s dependencies, installing the trixie package on Debian 12 will pull in lots of other packages from trixie (including libc6), which isn’t a great idea. You’d be better off rebuilding GCC or using a trixie container. Commented Dec 19, 2024 at 22:23
  • 1
    Thanks. I’m not the only one warning about such setups — there’s even a name for them, FrankenDebian. And while I’m sure you did test this, and it works fine now, the problem with these setups is that they’re liable to break in future — in particular, when the next version of Debian is released. Mixing a stable distribution with a rolling distribution is inherently risky; and if core packages such as libc6 are upgraded, that might lock the user out of tested upgrade paths. Commented Dec 20, 2024 at 11:13
  • 1
    An example scenario where this can leave a user stuck is if, during the development of Debian 13, an upgrade issue is discovered that requires a fix in Debian 12. This will be provided in a Debian 12 point-release, and is one of the reasons why the release notes always say that the first step in upgrading to release n+1 is to make sure the system is fully updated with respect to release n. Installing a newer package from Debian 13 during Debian 13’s development means that such point-release fixes to the upgraded packages won’t be applied. Commented Dec 20, 2024 at 11:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.