libstdc++.so.6エラーの原因と対処 — Claude Code

「libstdc++.so.6」エラーはmusl/glibcのバイナリを取り違えたサイン

Claude Codeをインストールした直後、コマンドを実行すると次のようなエラーで止まる場合があります。

Error loading shared library libstdc++.so.6: No such file or directory

libgcc_s.so.1が同じ文脈で出ることもあります。どちらも共有ライブラリが見つからないという表示ですが、原因はライブラリの欠落そのものではありません。インストーラーがシステムに合わないバイナリ変種をダウンロードしたことが根本原因です。

Linuxのバイナリ配布には大きく分けて2系統あります。Ubuntu・Debian・RHELなど大半のディストリビューションが使うglibc(GNU C Library)向けと、Alpine Linuxなど軽量ディストリビューションが使うmusl向けです。この2つはCの標準ライブラリの実装が異なり、一方向けにビルドされたバイナリはもう一方の環境では動きません。Claude Codeのインストーラーは実行環境を自動判定してどちらのバイナリを取得するか決めますが、この判定を誤るとlibstdc++.so.6のような見慣れないエラーで止まります。

厄介なのは、本来glibc環境なのにmusl向けバイナリが選ばれてしまうケースです。glibcベースのシステムにmuslクロスコンパイル用のパッケージ(musl-gccやmusl-devなど)が混在してインストールされていると、インストーラーの自動判定が環境をmuslと誤認することがあります。ビルド環境やCI用のDockerイメージでクロスコンパイルツールチェーンを併用している場合に起きやすい構成です。

自分の環境がmuslかglibcかを確認する

対処の前に、実行環境がどちらのlibcを使っているかを確定させます。判定にはlddコマンドを使います。

ldd --version 2>&1 | head -1

出力にGNU libcまたはGLIBCという文字列が含まれていればglibc環境です。muslという文字列が含まれていれば、実際にmuslベースの環境にいます。この結果と、インストーラーが実際に取得したバイナリの種類が一致しているかどうかが、次に取るべき対処を分けます。

対処1 — glibc環境なのにmuslバイナリを取得していた場合

ldd --versionがGNU libcを返すのにlibstdc++.so.6のエラーが出ている場合、インストーラーの誤判定です。まずインストールを削除し、再インストールします。

curl -fsSL https://claude.ai/install.sh | bash

再インストールしても同じ誤判定が繰り返される環境では、正しいバイナリ変種を手動で選んで取得する方法があります。Claude Codeのリリースには、バージョンごとにどのバイナリがどのプラットフォーム向けかを記したマニフェストファイルが公開されています。

https://downloads.claude.ai/claude-code-releases/{VERSION}/manifest.json

{VERSION}を対象のバージョン番号に置き換えて参照すると、glibc向け・musl向けそれぞれのダウンロードURLを確認できます。手動取得でも解決しない場合や、原因がクロスコンパイルパッケージの混在以外にありそうな場合は、ldd --versionの出力に加えて、/lib配下にmusl関連のファイルが紛れ込んでいないかをlsで確認した結果を添えてGitHub issue(github.com/anthropics/claude-code/issues)を報告してください。この確認は、システムに実際にmusl関連ファイルが紛れ込んでいるかを判断する直接的な手がかりになります。

対処2 — 実際にmuslベースの環境にいる場合(Alpine Linux等)

ldd --versionがmuslを返した場合は誤判定ではなく、実際にmusl環境で動かそうとしています。この場合、libstdc++.so.6のエラーはインストーラーの判定ミスではなく、実行時に必要な共有ライブラリそのものが未インストールであることが原因です。Alpine Linuxはこれらのパッケージをデフォルトで含みません。

apk add libgcc libstdc++ ripgrep

ripgrepはAlpineのメインリポジトリではなくcommunityリポジトリに収録されています。apkが「パッケージが見つからない」と報告する場合は、/etc/apk/repositoriesにcommunityリポジトリを追加してからapk updateでパッケージ索引を更新し、再度apk addを実行します。

echo "https://dl-cdn.alpinelinux.org/alpine/v3.22/community" >> /etc/apk/repositories
apk update
apk add libgcc libstdc++ ripgrep

Alpine環境では、このlibgcc libstdc++に加えてbashとcurlもデフォルトで含まれていません。インストールコマンド自体がnot foundで失敗する場合は、先にapk add bash curlを実行してからインストールスクリプトを流し直します。ripgrepをパッケージから導入した場合は、settings.jsonのenvにUSE_BUILTIN_RIPGREPを0で設定し、Claude Code内蔵のripgrepではなくシステム側のripgrepを使うよう明示しておくと、バージョン不整合による検索エラーを避けられます。

musl系ディストリビューションはAlpineだけではない

muslを採用しているのはAlpine Linuxが代表的ですが、uClibcベースの組み込み向けディストリビューションなど、他のmusl系環境でも同じ現象が起きます。ldd --versionの出力がAlpine特有のものでなくても、muslという文字列が含まれていれば対処の考え方は同じです。パッケージマネージャーのコマンド名だけがディストリビューションごとに異なる(apkではなくaptやopkgなど)ので、libgccとlibstdc++に相当するパッケージ名を各ディストリビューションのドキュメントで確認してください。

Dockerイメージやビルド環境で発生しやすい理由

このエラーがローカルの開発機よりもDockerコンテナやCI環境で目立つのには理由があります。軽量なコンテナイメージを作るために、ベースイメージとしてAlpine(musl)を選びつつ、その上でglibcバイナリ向けのビルドツールチェーンをインストールするような混成構成が一般的だからです。逆に、glibcベースのイメージにクロスコンパイル用のmuslツールチェーンを追加して、複数アーキテクチャ向けの成果物を一括ビルドする構成も珍しくありません。どちらの組み合わせも、Claude Codeのインストーラーからは「システムのlibc種別」を一意に決めにくい環境に見えます。

再現性が求められるCI環境では、インストール手順の中にldd --versionの結果を出力させておくと、後から同じ問題が起きたときの切り分けが速くなります。Dockerfileの中でインストール直後に確認コマンドを1行差し込むだけで、ビルドログに証跡が残ります。

WSL(Windows Subsystem for Linux)上でこのエラーに遭遇した場合も、判断の軸は同じです。WSLディストリビューションの多くはUbuntuなどglibcベースですが、Alpine WSLを選んでいる場合はmusl環境として扱う必要があります。wsl --list --verboseでディストリビューション名を確認し、Alpine系であれば対処2、それ以外であれば対処1の手順に進んでください。

よくある質問

libgcc_s.so.1が見つからないというエラーも同じ原因ですか

はい。libstdc++.so.6とlibgcc_s.so.1はどちらもglibc環境で必要になる共有ライブラリで、musl向けバイナリを誤って取得した場合にどちらか一方、または両方が見つからないというエラーになります。対処の手順は同じです。まずldd --versionで実際のlibc種別を確認してください。

aptやyumでもlibstdc++は入りますか

はい。Ubuntu・Debianであればapt install libstdc++6、RHEL・Fedora系であればyum install libstdcxxまたはdnf install libstdc++に相当するパッケージで導入できます。ただしこれはglibc環境で本来インストール済みのはずのライブラリなので、ディストリビューション標準のイメージでこのエラーが出ている場合は、パッケージの欠落よりもバイナリ変種の取り違えを先に疑ってください。

再インストールでも同じ誤判定が続きます

クロスコンパイル用パッケージ(musl-gccなど)がシステムに残っていると、インストーラーが再び環境をmuslと誤認する可能性があります。一時的にそれらのパッケージを削除してから再インストールを試すか、対処1で触れたマニフェストURLから該当バージョンのglibc向けバイナリを手動で取得してください。

USE_BUILTIN_RIPGREP=0はどんなときに必要ですか

Alpine LinuxなどmuslベースOSでripgrepをパッケージマネージャーから導入した場合に設定します。Claude Codeは通常、内蔵のripgrepバイナリを使いますが、この内蔵バイナリもmusl/glibcの区別の影響を受けます。システム側のripgrepを明示的に使わせることで、内蔵バイナリ周りの不整合を避けられます。

npmでインストールした場合もこのエラーは起きますか

起きます。npmパッケージ経由でも、プラットフォームごとのオプション依存パッケージとしてdarwin-arm64 darwin-x64 linux-x64 linux-arm64とそれぞれのmusl版、win32-x64 win32-arm64のいずれかが選ばれる仕組みは同じです。判定ロジックが共通しているため、ネイティブインストーラーとnpmインストールのどちらでも同じ誤判定が起こり得ます。

判定コマンドの結果をどう報告すればよいですか

原因が特定できない場合は、ldd --versionの出力とls /lib/libc.musl*の実行結果をそのまま添えてGitHub issue(github.com/anthropics/claude-code/issues)に報告してください。libc.musl系のファイルが存在するかどうかは、システムにmusl関連ファイルが実際に紛れ込んでいるかを判断する材料になります。

まとめ

libstdc++.so.6やlibgcc_s.so.1が見つからないエラーは、ライブラリの欠落そのものではなく、musl向けバイナリとglibc向けバイナリの取り違えが原因です。ldd --versionで実際のlibc種別を確認し、glibc環境なのにmuslバイナリを取得していたら再インストールかマニフェストからの手動取得、実際にmusl環境(Alpine Linux等)にいるならapk add libgcc libstdc++ ripgrepで必要なライブラリを補います。インストール全体の切り分けはClaude Codeインストールエラーの切り分けチェックリスト、Ubuntu特有の依存関係はClaude Code Ubuntuインストールにまとめています。