linux.yml: Upgrade from GCC 12 to GCC 13 + add GCC 9

[hartwork]

No description provided.

[j6t]

Why? Just because we can?

We developers tend to work with the shiniest new things ourselves, and forget that there are old systems out there which don't have the newest stuff. We notice errors caused by the new compilers ourselves, but miss problems that occur with old compilers. If we change something, wouldn't it be better to downgrade the compiler?

[hartwork]

Hi @j6t,

Why? Just because we can?

no 😃 :

• The CI ideally covers all compilers that are considered relevant (by you and/or users) that are reasonably economic to cover. I'm happy to discuss which versions of GCC you consider relevant, I'm here to help, nothing against GCC 12.
• GCC 13 is relevant in my book because it's only a matter of "when" related issues would need to be fixed rather than "if". So it makes sense to me to add GCC 13 to the CI some way.
• These days compilers tend to grow stricter and stricter — Clang in particular, which I find is both annoying and important at the same time — so unless code has pre-processor level checks for specific versions of compilers, covering more recent compilers seems more important than covering older ones, but I'm only referring to compilers here not libraries or distros.
• It's not uncommon to cover both the oldest and most recent version supported for an economic approach. I'm happy to make the CI cover say GCC 11 and 13 or something like that.

What do you think?

We developers tend to work with the shiniest new things ourselves, and forget that there are old systems out there which don't have the newest stuff. We notice errors caused by the new compilers ourselves, but miss problems that occur with old compilers. If we change something, wouldn't it be better to downgrade the compiler?

Being the maintainer of https://github.com/libexpat/libexpat myself I believe I am very aware of support for older systems in general, e.g. version requirements of MSVC and Autoconf and CMake cover quite a bit of legacy there and have to. I think I addressed the downgrade aspect above, I'm happy to add older versions of GCC to the mix, as you see fits. Let me know!

Have a nice Sunday, best, Sebastian

[j6t]

I buy the argument that newer compilers are stricter and more likely to notice errors.

As to which compilers are relevant, I do not know. It's probably answered by knowing what the oldest distributions are that are relevant. Debian is usually the one stuck with the oldest compiler, I would imagine, but where that is these days, I don't know. Do you?

Heh, looks like here on openSUSE 15.4 I am still using gcc 7 if I ask for just gcc without a specific version. Outch!

[hartwork]

I buy the argument that newer compilers are stricter and more likely to notice errors.

@j6t excellent!

As to which compilers are relevant, I do not know. It's probably answered by knowing what the oldest distributions are that are relevant. Debian is usually the one stuck with the oldest compiler, I would imagine, but where that is these days, I don't know. Do you?

Heh, looks like here on openSUSE 15.4 I am still using gcc 7 if I ask for just gcc without a specific version. Outch!

With what we have for a current base image in the CI — ubuntu-22.04 our economic options are probably…

• 9.5.0
• 10.5.0
• 11.4.0
• 12.3.0
• 13.1.0

…according to https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#language-and-runtime. The next older image — ubuntu-20.04 — has…

• 9.4.0
• 10.5.0

…according to https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2004-Readme.md#language-and-runtime .

How about GCC 9.5.0 and GCC 13.1.0 for KDbg CI?

[j6t]

How about GCC 9.5.0 and GCC 13.1.0 for KDbg CI?

That sounds great!

[hartwork]

How about GCC 9.5.0 and GCC 13.1.0 for KDbg CI?

That sounds great!

@j6t done, good enough?

[hartwork]

@j6t anything missing here for a merge?

[j6t]

I would have appreciated if there had been some justification for the changes in each of the commit's messages. Answer the question why we need this change. If the answer is "because we can", then the change is not warranted. Never assume that everybody who sees the change knows automatically why it is a good change.

(If you redo the commits, please do not rebase to the tip of master; keep the same branch point.)

[hartwork]

Hi @j6t,

I would have appreciated if there had been some justification for the changes in each of the commit's messages. Answer the question why we need this change. If the answer is "because we can", then the change is not warranted. Never assume that everybody who sees the change knows automatically why it is a good change.

I have added comments to these two commits now, at least the GCC 13 one was pretty obvious already, but okay.

(If you redo the commits, please do not rebase to the tip of master; keep the same branch point.)

I would have done the opposite but sure I can follow that rule here, the base commit should be unchanged.

@j6t ready to merge?

[j6t]

Thank you, looking very good! Merged.

[j6t]

@hartwork Any idea why the gcc-13 job (Ubuntu) suddenly fails? One example is here. Is GCC 13 not installed anymore in the Ubuntu image?

[hartwork]

@j6t yes, I have an idea:

• Ubuntu 22.04, GNU C++ 13.1.0 removed from image 20240514.2.1 actions/runner-images#9866
• [Ubuntu] ubuntu-toolchain-r/test repository will be removed from images on May 13 actions/runner-images#9679

It affected me in multiple other places. Let me try offer a pull request here, give me a minute…

[hartwork]

@j6t here you go: #40