TL;DR

原因：Debian TrixieでOpenGL関連ライブラリのパッケージ名が変わっていた。libgl1-mesa-glxは死亡。

解決策：以下をインストール。

sudo apt-get update && sudo apt-get install -y --no-install-recommends \
    libgl1 \
    libglib2.0-0t64 \
    libsm6 \
    libxext6 \
    libxrender1 \
    libgomp1

教訓：Dockerfileに環境依存を焼き込むな。コンテナ内で都度対応が現実。

背景

WSL2 + Docker + Dev Containers で Python3.13の開発環境を構築。Jupyter上で grad-cam を使ってGradCAMの可視化をしようとした。

from pytorch_grad_cam import GradCAM, ScoreCAM, GradCAMPlusPlus, HiResCAM, LayerCAM

あ、落ちた。

ImportError: libGL.so.1: cannot open shared object file: No such file or directory

なんもしてないのに壊れた。厳しいって。

環境情報

OS: Debian Trixie (on WSL2)
Python: 3.13
Docker Image: python:3.13-slim
Dev Containers: VSCode最新
依存ライブラリ: grad-cam, opencv-python, torch, torchvision

問題発生

Dockerfileに以下を追加して再構築したのに、同じエラーが繰り返す。

RUN apt-get update && apt-get install -y --no-install-recommends \
    libgl1-mesa-glx \
    libglib2.0-0 \
    libsm6 \
    libxext6 \
    libxrender-dev \
    libgomp1 \
    && rm -rf /var/lib/apt/lists/*

コンテナ再構築しても反応なし。docker system prune -a --volumes しても無視。

Package 'libgl1-mesa-glx' has no installation candidate

パッケージが消えてた。つまり、古いDocker手順でコンテナ作ったら、Debian Trixieではそのパッケージはもうない。気づくの遅い。python3.16はもう始まってるって。

原因

Debian Trixieでパッケージ名が刷新された。

旧パッケージ名	新パッケージ名
`libgl1-mesa-glx`	`libgl1`
`libglib2.0-0`	`libglib2.0-0t64`
`libxrender-dev`	`libxrender1`

古い手順をコピペしてたら、アーキテクチャ対応の変更を見逃す。よくある話。

python:3.13-slim は Debian Trixie をベースにしてる。つまり、2024年後半にセットアップした人は全員これに引っかかる。

ガチで危機感持った方がいいって。

解決策

ステップ1：コンテナ内で直接インストール

すでにコンテナが起動してるなら、一度実行してしまえ。

sudo apt-get update && sudo apt-get install -y --no-install-recommends \
    libgl1 \
    libglib2.0-0t64 \
    libsm6 \
    libxext6 \
    libxrender1 \
    libgomp1

即座に動く。Dockerfileの再構築より早い。

ステップ2：Dockerfileに正しい依存を焼き込む（推奨）

FROM python:3.13-slim

ENV PYTHONUNBUFFERED=1 \
    PYTHONDONTWRITEBYTECODE=1 \
    UV_CACHE_DIR=/tmp/.uv-cache \
    UV_PYTHON=python3.13

# Debian Trixie対応のシステムライブラリ
RUN apt-get update && apt-get install -y --no-install-recommends \
    git \
    curl \
    build-essential \
    libgl1 \
    libglib2.0-0t64 \
    libsm6 \
    libxext6 \
    libxrender1 \
    libgomp1 && \
    rm -rf /var/lib/apt/lists/*

COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv

WORKDIR /workspace

RUN useradd -m -s /bin/bash vscode && \
    chown -R vscode:vscode /workspace

USER vscode

ENV PATH="/workspace/Image_marimo/.venv/bin:/workspace/Table_marimo/.venv/bin:/home/vscode/.local/bin:${PATH}"

CMD ["/bin/bash"]

ポイント：

libgl1-mesa-glx → libgl1
libglib2.0-0 → libglib2.0-0t64
libxrender-dev → libxrender1

その後、Dev Containerを再構築。

VSCode: "Dev Containers: Rebuild Container"

ステップ3：Notebookで動作確認

from pytorch_grad_cam import GradCAM, ScoreCAM, GradCAMPlusPlus, HiResCAM, LayerCAM
from pytorch_grad_cam.utils.image import show_cam_on_image
from pytorch_grad_cam.utils.model_targets import ClassifierOutputTarget
#動いた

教訓

古いDocker手順を信じるな
- パッケージ名は年単位で変わる。
- 公式ドキュメント > ネット記事。
コンテナ内で都度対応するのも戦略
- Dockerfileの完全性を求めるより、起動後の微調整が速いときがある。
- 本番環境なら焼き込め。開発中なら走りながら治す。
Debian/Ubuntu のライブラリ名は t64 チェック
- 最近のDebianは64ビット対応で t64 が追加される傾向。
- libglib2.0-0 → libglib2.0-0t64 のように。

結論、お前らが古い手順で環境構築していた時間、俺はDebian Trixieのドキュメント読んでた。周りは待ってくれないって。

技術は前に進む。Docker Hub の base image も更新され、パッケージ名も変わる。動作環境を固定しない限り、追従が必須。

動く環境が正義。甘えんなって。

参考資料