Lesstep
GitHub Actions・Ubuntu 26.04・2026年11月4日に確認

ubuntu-latest（Ubuntu 26.04）の GCC 15 で通らなくなった C と C++ のビルド

ubuntu-latest は、2026年10月19日から11月19日にかけて Ubuntu 24.04 から 26.04 に移ります（ほかに変わること）。既定の gcc と g++ は GCC 13 から GCC 15 に上がります（24.04 のイメージは 13.3.0、26.04 のイメージは 15.2.0）。既定が GCC 14 を飛ばすので、2つのリリースぶんの変更が一度に来ます。昨日まで通ったコードが、make で、C の拡張を持つパッケージの pip install で、あるいは下で C をコンパイルする Rust や Go のビルドで落ちます。

どの変更か

ほとんどは3つの型のどれかです。ある型を直すフラグは、ほかの型には効かないので、まず最初のエラーを見ます。

1. C が既定で C23 になった（GCC 15）

GCC 15 は C を -std=gnu23 でコンパイルします。GCC 13 と 14 は -std=gnu17 でした（Porting to GCC 15）。C23 では空の引数の並び () は (void) の意味になり、bool・true・false・nullptr・thread_local はキーワードです。ubuntu-latest の HDF-EOS5（hdf5 #6841）と GCC の案内から：

error: too many arguments to function 'pakr2dm'; expected 0, have 1
error: passing argument 8 of 'inv_init' from incompatible pointer type [-Wincompatible-pointer-types]
error: 'bool' cannot be defined via 'typedef'

わかりにくいのは、C の版で切り替わるマクロから来るものです。libmdbx は C23 では [[maybe_unused]] に展開され、「expected identifier or '(' before 'static'」で落ちます（lighthouse #10518）。

2. 警告がエラーになった（GCC 14）

GCC 14 は、古い6つの警告をエラーにしました。暗黙の関数宣言、暗黙の int、int-conversion、incompatible-pointer-types、return-mismatch、declaration-missing-parameter-type です（Porting to GCC 14）：

error: implicit declaration of function 'strlen' [-Wimplicit-function-declaration]

pylzma 0.5.0（2018年）は pip install で「makes integer from pointer without a cast」で落ちます（hera #1140）。気づきにくいのは configure です。確かめ用のプログラムがコンパイルできなくなるので、入れたはずのライブラリが無いと判断します。hdf5 #6841 では「szlib is not functional」と出ました。

3. C++ のヘッダーがほかのヘッダー経由で入らなくなった（GCC 15）

libstdc++ のヘッダーどうしが互いを読み込む量が減り、よく引っかかるのは <cstdint> です（Porting to GCC 15）：

error: 'uint64_t' does not name a type
note: 'uint64_t' is defined in header '<cstdint>'; this is probably fixable by adding '#include <cstdint>'

自分のコードではなく、依存先にあることが多いです。直る前の版に固定した ITK（ITKR #79）や、Rust の rocksdb クレート 0.22.0 が cc-rs で組み立てる RocksDB 8.10.0 です。

型1の直し方：C を C17 でコンパイルする

本当の直し方は、関数に引数を書き、キーワードと重なる名前を変えることです。先にビルドを緑にするなら、前の既定を指定します：

env:
  CFLAGS: -g -O2 -std=gnu17

-g -O2 は残します。CFLAGS を決めると、configure が使うはずだった既定が置き換わるからです。Autotools・setuptools（つまりソースからの pip install）・Rust の cc クレートは CFLAGS を読みます。そのほか：

lighthouse #10518 は、libmdbx の修正が入るまで slasher のテストをこの形で組み立てます。

型2の直し方：宣言を足す

note が示すヘッダーを読み込むか、関数を宣言します。自分のコードでなければ、まず新しいリリースを探します。pylzma には2026年1月から 0.6.0 と 0.6.1 があります。その場しのぎなら、-fpermissive で C のこれらのエラーを警告に戻せます。1つずつ戻すなら：

env:
  CFLAGS: -g -O2 -Wno-error=implicit-function-declaration -Wno-error=int-conversion

hdf5 は configure に -Wno-error=implicit-function-declaration を渡して、szlib の確かめを通るようにしました。CFLAGS をすべての段に渡さないビルドもあり、GCC 14 の案内はそういうときに CC="gcc -fpermissive" を勧めています。

型3の直し方：依存先を上げるか、include を足す

どの -std でもヘッダーは戻りません。include が抜けているライブラリを上げます。drasi は rocksdb クレートを 0.22.0 から 0.24.0 に上げ、RocksDB は 10.4.2 になりました（drasi-core #1000）。ITK は2025年6月にヘッダーを直しています。まだ上げられないなら、CXXFLAGS: -include cstdint ですべての C++ のファイルにそのヘッダーを足せます。

または 24.04 と同じ GCC を使う

26.04 のイメージにも gcc-13 と gcc-14 があります（g++-13 は 13.4.0、g++-14 は 14.3.0）。ビルドを GCC 13 に向ければ、3つの型のどれも起きません：

env:
  CC: gcc-13
  CXX: g++-13

Autotools・CMake（新しいビルドディレクトリで）・setuptools・cc-rs・cgo は CC と CXX を読みます。もう1つの逃げ道は、そのジョブを runs-on: ubuntu-24.04 にすることで、GitHub が 24.04 のイメージを終えるまで使えます。どちらも時間を稼ぐだけで、次のコンパイラーのためにはコードを直す必要があります。

見分け方

ほかの 26.04 の失敗

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

JetBrains Marketplace で入れる

GitHub と GitHub Actions は GitHub, Inc. の商標、Ubuntu は Canonical Ltd. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・Canonical・GCC のプロジェクト・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：「The ubuntu-latest label will migrate to Ubuntu 26」 · Ubuntu 26.04 の「cannot open shared object file」 · Ubuntu 26.04 の setup-ruby の「Unavailable version」 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English