VSCodeのパッケージ不適合によるエラー解決までの道のり（Byebug編）
この記事はフィヨルドブートキャンプ Part 2 Advent Calendar 2022 - Adventarの22日目の記事です。昨日のエントリーは、
Part 1がobregonia1さんの業務未経験からWEBエンジニアに転職して一年弱経ちました | Code Rules Everything Around Me
Part 2がyamabe009さんのフィヨルドブートキャンプで学習する2児ワーママのとある一日 - やまべのブログ でした。
フィヨルドブートキャンプの今年のアドベントカレンダーは以下の通りです。
フィヨルドブートキャンプ Part 1 Advent Calendar 2022 - Adventar
フィヨルドブートキャンプ Part 2 Advent Calendar 2022 - Adventar
はじめに
2021年の春より、フィヨルドブートキャンプにてプログラミングを学習しているのですが、学習を進めていく中でByebugというRubyのデバッグツールを使う機会がありました。その際、エラーによりByebugを使うことができず、解決までに数日かかってしまいました。
エラーの原因なのですが、なんとVSCodeをインストールした際に発生していました。
今回はByebugで起こったエラーについて、事の顛末を書いていこうと思います。
自分の場合はByebugでエラーが発生しましたが、今はByebugはあまり使われていないようです。しかし、原因がByebugに由来していないため、他のgemなどでも発生する可能性があるかもしれません。
また、エラーに遭遇したのは昨年ですが、まだエラーが発生する可能性が考えられるため備忘録という形で残しておきたいと思います。
エラー発生時のバージョンについて
パソコンおよびruby、インストールを試みたByebugのバージョンは以下の通りです。
- パソコン：MacBook Air (M1, 2020)
- パソコン内のチップ：Apple m1
- バージョン：Mac OS Big Sur バージョン11.4
- ruby：ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [arm64-darwin20]
- Byebug：byebug-11.1.3
結論
使用していたVSCodeのパッケージが、使用しているMacに適していなかったため。 チップが「Apple M1」の場合、VSCodeをインストールする際は「Apple Silicon」を選ぶ。
解決までの経緯
エラーの発生
フィヨルドブートキャンプにて、rubygemsに関する学習を行っていたときのことです。 byebugによるデバッグを体験するために、gemコマンドを使用してbyebugをインストールしました。
% gem install byebug Fetching byebug-11.1.3.gem Building native extensions. This could take a while... Successfully installed byebug-11.1.3 Parsing documentation for byebug-11.1.3 Intalling ri documation for byebug-11.1.3 Done installing documentation for byebug after 8 seconds 1 gem installed
インストール自体はできたのですが、byebug -vでバージョンを確認しようとすると、以下のエラーが発生します。
% byebug -v
Traceback (most recent call last):
9: from /Users/hoge/.rbenv/versions/2.7.3/bin/byebug:23:in `<main>'
8: from /Users/hoge/.rbenv/versions/2.7.3/bin/byebug:23:in `load'
7: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/exe/byebug:4:in `<top (required)>'
6: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'
5: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'
4: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/runner.rb:5:in `<top (required)>'
3: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/runner.rb:5:in `require_relative'
2: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/core.rb:4:in `<top (required)>'
1: from /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'
/Users/hoge/.rbenv/versions/2.7.3/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require': dlopen(/Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/byebug.bundle, 9): no suitable image found. Did find: (LoadError)
/Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/byebug.bundle: mach-o, but wrong architecture
/Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/byebug.bundle: mach-o, but wrong architecture - /Users/hoge/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/byebug-11.1.3/lib/byebug/byebug.bundle
解決策を調べていたのですが、インターネット上では見つけることができなかったため、フィヨルドブートキャンプ内のQ&Aに質問を投稿しました。すると、メンターの@jnchitoさんから回答をいただき、一緒に解決策を考えていただけることになりました。
Rubyを最新版にする（解決せず）
はじめにrubyをエラー発生時の最新版である2.7.4に変更し、byebugをもう一度インストールして実行するよう提案いただきました。 Ruby2.7.4をインストール後、Byebugをインストールしバージョンを確認しましたが同じようなエラーが出ました。
byebugインストール時にplatformを指定する（解決せず）
次にbyebugを一度アンインストールした後gem install byebug --platform=rubyでインストールするよう提案いただきました。
platformがrubyであることを指定する形です。
guides.rubygems.org
提案いただいた方法でインストールをします。インストール自体は成功したように見えます。
% gem install byebug --platform=ruby Fetching byebug-11.1.3.gem Building native extensions. This could take a while... Successfully installed byebug-11.1.3 Parsing documentation for byebug-11.1.3 Installing ri documentation for byebug-11.1.3 Done installing documentation for byebug after 8 seconds 1 gem installed
しかし、バージョンを確認すると最初と同じエラーが発生しました。
brew doctorの実行
ここから@jnchitoさんと1on1でデバッグ作業を行い、エラーの解決を試みることになりました。
まず、brew doctorを実行しました。
% brew doctor Please note that these warnings are just used to help the Homebrew maintainers with debugging if you file an issue. If everything you use Homebrew for is working fine: please don't worry or file an issue; just ignore this. Thanks! Warning: Your Homebrew's prefix is not /usr/local. Some of Homebrew's bottles (binary packages) can only be used with the default prefix (/usr/local). You will encounter build failures with some formulae. Please create pull requests instead of asking for help on Homebrew's GitHub, Twitter or any other official channels. You are responsible for resolving any issues you experience while you are running this unsupported configuration.
「Warning: Your Homebrew's prefix is not /usr/local.」と書かれているため、Homebrewに問題があるのではないかとの仮説が立ちました。/usr/local配下にHomebrewがインストールされていない可能性がありそうです。
which -aとbrew configを実行
次に、homebrewについて同じような状況になっている人のissueを参考に、which -aとbrew configを行うことになりました。
github.com
whichは実行コマンドのフルパスを表示するコマンドで、aオプションをつけると環境変数PATHにある全ての実行ファイルを表示することができます。また、brew configではHomebrewの構成を確認することができます。
atmarkit.itmedia.co.jp
自分と@jnchitoさんはMacBookの機種以外ほぼ同じ環境だったのですが、brew configを行った際に、macOSとRosetta 2の部分がそれぞれ異なっていることが分かりました。
Rosetta 2は以下の記事によると、「従来のIntel Mac用のバイナリをArmベースのM1 Macでも動くようにさせるためのエミュレーションソフト」とのことです。
blogs.itmedia.co.jp
自分はmacOS: 11.4-x86_64、Rosetta 2: trueだったのですが、@jnchitoさんはmacOS: 11.4-arm64、Rosetta 2: falseでした。ここで、Homebrewに設定されたmacOSのCPUアーキテクチャがx86_64になっていることがエラーの原因かもしれない、という話になりました。
GCCのバージョンを確認する
次にgcc --versionを実行し、GCCのバージョンを確認していきます。
GCCとは、「GNUプロジェクトが開発および配布している、さまざまなプログラミング言語のコンパイラ集」とのことでした。
% gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.5.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin
ここでも、本来arm64から始まるはずのTargetの部分が、Target: x86_64-apple-darwin20.5.0になっていました。
Xcode Command Line Tools の再インストール（解決せず）
次にXcode Command Line Toolsの再インストールを行い、brew configやgcc --versionを実行した時にそれぞれmacOSとTargetが arm64と付く形になるかどうか確認していきました。
Xcode Command Line Toolsの再インストールに関しては、以下の記事を参考にしました。
blog.hgrs.me
再インストールが済んだ後、gcc --versionを実行しましたが、Target: x86_64-apple-darwin20.5.0のままでした。
uname -mを実行
次に、uname -mを実行しました。
unameは「カーネルの名前やバージョン、ハードウェア名などを表示するコマンド」で、mオプションを付けることでハードウェア名を表示させることができます。
% uname -m x86_64
m1チップを搭載したパソコンの場合、本来はarm64と表示されます。しかし実行結果はx86_64でした。
ここでTerminalを実行する際に、x86_64を基にしてByebugなどのプログラムが実行されていることがエラーの要因だと把握できてきました。
Macのターミナルでbrew configを実行
今まではVSCodeのターミナルを使ってコマンドを実行してきましたが、一応Macに元々付いているターミナルでbrew configを実行してみました。
すると、macOS: 11.4-arm64、Rosetta 2: falseと適切な設定になっています。不思議に思いつつ試しにbyebug -vを実行しました。
% byebug -v Running byebug 11.1.3
問題なくバージョンが表示されています。
ここで原因はhomebrewではなく、VSCodeにあるのでは？となり、VSCodeのバージョン情報を確認しました。
OSの部分が「Darwin x64 20.5.0」になっています。
ついにエラーの原因が、「パソコンのCPUアーキテクチャ（arm64）と不適合なVSCodeのパッケージを使用していたため」だったことが分かりました。
VSCodeを再インストール（エラー解決につながる）
x64が使われているVScodeをアンインストールし、以下のリンクよりApple SiliconパッケージのVSCodeをインストールしました。
「Apple silicon」（画像の丸がついている部分）をクリックしダウンロード・インストールを行います。
※以下のページによると、デフォルトのダウンロードはすべてのMacで動作するUniversalパッケージになっているとのことです。大きなボタンになっている箇所をクリックすると、Universalパッケージでインストールされると思われます（未検証）。
以前どのボタンを押してインストールを行ったか失念していたため、念の為「Apple Silicon」を選択しています。
インストール完了後にバージョン情報を確認すると、OSの部分がarm64に変わっていました。
byebug -vを実行する（解決）
gem uninstall byebug、gem install byebugを実行し、Byebugのアンインストール&再インストールを行いました。
その後、VSCodeのターミナルでbyebug -vを実行しました。
% byebug -v Running byebug 11.1.3
エラーは発生せず、VSCodeのターミナルでもバージョン情報が表示されました。
終わりに
今回Byebugで起こったエラーは、VSCodeが自分のパソコンと適していないパッケージだったことが原因で発生しました。意外なところにエラーの原因が潜んでいる場合があることを身をもって知った形です。エラーの根本的な原因が解決できていなかったら、他のツールを実行した場合もエラーが発生していたのかもしれません。
また、エラー解決のために様々な策を提案してくださった@jnchitoさんがいたことで、エラーを解決することができたと思います。ありがとうございます！
明日はPart 1がはるぐち ゆうまさん、Part 2がwataさんになります。楽しみです！
