compile error of ide4gr on macosx for gr-citrus

エラーの内容は IDE for GR が使用しているコンパイラの内部エラーであり Java は関係なさそうです。

> 試したのは利用開始例にある”Fading”です。"PIN_LED0"の変更は行いました。

にある「変更」とは http://gadget.renesas.com/ja/product/citrus_sp3.html にある

> スケッチの中にある"ledPin"を9ピンから"PIN_LED0"に変更します。

のことでしょうか? 変更を行わずにビルドした場合でも同様のエラーは発生しますか?

エラー中の

/Users/shio/tmp.ide4gr/build2612602148285772166.tmp/Fading.cpp

はテンポラリで作成された C++ のソースファイルですが、これの内容はどうなってますか?

念のため私のMacで（まだYosemiteのままなのですが）試してみましたが、問題なくコンパイルと書き込みができました。

Fading.cppの内容は気になるところなのですが、Fadingサンプルを読まずに、IDE4GRを起動した時点の何も変更しない状態でチェックボタンを押してもエラーになりますでしょうか？

NoMa様、fujita様、

いろいろとコメントありがとうございます。

基本的(？)なことですが、IDE4GRでは、これのinstall以前にMacOSXへ組み込まれたgccのライブラリなどを利用しているのでしょうか？

私は、IDE4GRはこれだけで完全に閉じた開発システムと思っていたのですが。閉じていないから今回のようなエラーが起きるということでしょうか？これは単純な疑問ですが。

h50baraさん、こんにちは。
私は閉じていると思っています。ですが、オペレーティングシステム側にそれを混乱させてしまう程の自由度を
後付け出来る機能が備わっている、ということなのでは?と考えています。(むしろその自由度があること(或いは
その自由度を意図的に保持しておくこと)がLinuxやGNUツールでメリットと考えられているかも知れません。
そして、それがMac OSやGNURXにも継承されている(或いは継承されて『しまった』?)というような感じです。)

あと、LinuxとGCCのライブラリは、WindowsでのMFCや.NETと同様に、一心同体(渾然一体)の関係にあるように
思えます。オペレーティングシステム側(それは、あまたのGNUツールや諸々のオープンソースツールを含みます)が
そもそもGCCでビルドされ、GCCのライブラリを使っている状況ですので、IDE4GRのGNURXに同梱されている
GCCのライブラリの同等物と何らかの干渉を起こしてしまう可能性は(GNURXに限らず)やむを得ない気もします。

と、ここまで書いて気付いたのですが、Mac OSのビルドに使われているのは、GCCでは無くてCLANGでしたっけ、、、

それから、原因がGMPライブラリかどうか確定した訳ではないですが、このライブラリはGCC専用ライブラリという
訳では無くて、あまたあるオープンソースライブラリの1つです。ある時点から、GCCはこのライブラリに依存する
ようになって、有志の人や企業/団体が配布しているGCCバイナリッケージに同梱されるようになったものだと認識
しています。(同様のものにMPCライブラリというものもあります。)

> 基本的(？)なことですが、IDE4GRでは、これのinstall以前にMacOSXへ組み込まれたgccのライブラリなどを利用しているのでしょうか？

IDE for GR やそれから呼ばれるツールチェーンが実際どうなっているかはわかりませんが、アプリケーションに対してライブラリが静的リンクになっている場合以外は動的にリンクされるライブラリが使用されることは普通にあることです。Mac がどうだかわかりませんが Windows ではアプリケーションとそれらで使用される .DLL が別に配布される状況はごく普通です。Javaや.NETの普及によりアプリケーションとライブラリの分離は更に進んだとも思います。

すみません。思い返してみると、Linuxや最近のWindowsのLinux互換環境(MSYS2)ではパッケージマネージャで
GCCをインストールしていましたので、これらのGCCが閉じているのか開いているのか把握していた訳ではなかった
ことに気付きました。以下の『有志の人や企業/団体が配布しているGCCバイナリッケージに同梱され』というのは、
言い過ぎました。すみません。
>それから、原因がGMPライブラリかどうか確定した訳ではないですが、このライブラリはGCC専用ライブラリという
>訳では無くて、あまたあるオープンソースライブラリの1つです。ある時点から、GCCはこのライブラリに依存する
>ようになって、有志の人や企業/団体が配布しているGCCバイナリッケージに同梱されるようになったものだと認識
>しています。(同様のものにMPCライブラリというものもあります。)

Mac用にGCCのコンパイルをしていただいたエンジニアにヒアリングしました。

原因は分かっていませんが、もしEFI32ビットの場合、申し訳ありませんが動作が困難の状態とのことです。

以下の通り転記いたします。

------------------------------------------------

はっきりとした要因は分かりませんが、

Xcodeに限らず、種々のソフトウェアのインストール環境、

およびパス設定の違いによって、IDEforGRのGCCが

変な位置にあるツール類（GCCから呼び出すCC、ASなど）に

アクセスしにいっているような雰囲気です。

「無理矢理MacOSX10.9へupgradeしている」

ということですので、Xcodeも古いGCCベースのものが残存していて、

そちらが影響しているという可能性もあります。

あとは、使用しているMacProの型番を確認していただいて、

初期のものだとすればファームが「EFI32ビット」なので、

サポート対象外でおそらく動作させるのは無理かと思われます。

「無理矢理MacOSX10.9へupgrade」

は、以下のサイトのような手段で行っているのかと思います。

90luck.blogspot.jp/.../mac-promac-os-x-1092.html

-------------------------------------------------

h50baraさん、こんにちは。

Rulzの新参者、かつ、どこの馬の骨か分からない輩、である私の薀蓄はさておき(ちょっと身も蓋も無いですが)、
せっかく買ったGR-CITRUSが長年使って来たMacProで動かない件は、即効性の特効薬のようなものは無さそう
な感じです。(藤田様も所謂『打ち出の小槌』とか『銀の弾』に相当するようなものが思い付かないようですし、岡宮様
からはギブアップ宣言に近いようなリプライもありましたし。) 地味で泥臭い作業で根気よく調べていくしか無さそう
な気がしています。どうしましょうか?

実は、私も先日買ったGR-CITRUSが謎のWindowsドライバインストールエラーを起こして、自分のパソコンでは
使えないのかも、と肝を冷やしたばかりだったので、他人事とは思えなくて色々投稿してしまったのですが、、、
(結局、私の場合は、そうなるのは理屈からして当然だった、ちょっとGR-CITRUSを操作すれば何の問題も無かった、
というのが分かって、それ以後、何事も無く使えたのですが、、、)

ちなみに、私のWindows7も常識では考えられないぐらい大昔のマシンにインストールしてあったりします、、、

よく考えてみたらide4grのダウンロードページは、Win用/MAC用、って書かれてるだけで、OSのversion等については未記載ですね。。

折角なので、そのへん更新されても良いのかな、と。

Xcodeに限らず、種々のソフトウェアのインストール環境、およびパス設定の違いによって、IDEforGRのGCCが変な位置にあるツール類（GCCから呼び出すCC、ASなど）にアクセスしにいっているような雰囲気です。

呼ばれる as が違うことでのアセンブルエラーであれば、例えば以下のコード

void setup() {
    asm("hogera");
}

void loop() {
}

をIDE for GR 0.8.0 Windows用でビルドした場合、

C:\Users\fujita\AppData\Local\Temp\cc8scQjF.s: Assembler messages:
C:\Users\fujita\AppData\Local\Temp\cc8scQjF.s:452: Error: Unknown opcode: hogera

アセンブラでのエラーと適正に報告されるので、今回の件は違う感じですね。

岡宮さん、

OSX用に独自ビルトしたツールチェーンであれば、

Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.kpitgnutools.com> for instructions.

OSX 版をリリースしていない、他 OS 版のサポートも既に別会社となっているところの KPIT のアドレスが出るのは宜しくないのでは?

皆様、

h50baraです。

多くのコメントをありがとうございました。今回試している環境は、Mac Pro(Mid 2006、1.1)にSFOTTというツールを利用してEFI64専用のOSXへupgrade(snow leopardからMarvericksへ)させたものです。クリーンインストールしていないので、古いEFI32でのライブラリが残っている可能性はあると思います。xcodeは以前よりinstallしており、現在はこのOSで動く最新版になっています。

IDE4GRは職場のMac、およびこのMacのVMwareFusion下のWinXPで動作しているので、当面このMacOSXでの使用は諦めます。特殊環境下での不具合なのでしょう。仕事の一部での組込機器開発はe2studio/HEWですし、あくまで趣味の範疇での使用なので、頂いた情報を元に今後自助努力で対応を考え、解決したら報告致します。

お手数をおかけしました。

h50baraです。解決はしていませんが、新規確認情報を追記します。

まず、IDE4GRは新規購入したMacPro(OSはEl Capitan)では正常動作しますが、少し古いMacBookPro(同じOS)では自宅のMacProと同じ症状になります。これは現行のOSへの移行がAppleで保証されている機種です。こちらもクリーンインストールではないのが影響しているかもしれません。

このMacBookPro上で、ボードの設定を切り替えて、setup()とloop()が空のスケッチをコンパイルすると、SAKURAとCITRUSは同じ関数での同じエラー終了、COTTONは別の関数で同じエラー終了、KURUMIは警告が1つ出るも完了、KAEDEは複数の警告が有るも完了、PEACHは正常に完了、という具合でした。

CPU種別で分けられるのかと思ったのですが、そう単純では無いですね。ご報告まで。

まとめると

RX:

SAKURAとCITRUSは同じ関数での同じエラー終了

KAEDEは複数の警告が有るも完了

RL78:

COTTONは別の関数で同じエラー終了

KURUMIは警告が1つ出るも完了

RZ:

PEACHは正常に完了

ということですが、Mac 用として配布されてる IDE for GR が内部で使用しているツールチェーンは、RX と RL78 のが KPIT が公開していたものを Mac 用に再ビルドしたもの、RZ  は https://launchpad.net/gcc-arm-embedded で Mac用に公開されているものだと思います。動作の傾向は RZ とそれ以外で大別して良いと思います。

RX と RL78 の両方のターゲットで問題が出たりでなかったりということですが、問題が出た際には

/Applications/IDE4GR.app/Contents/Java/hardware/tools/gcc-rx/rx-elf/rx-elf/bin/rx-elf-gcc -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/variants/gr_citrus -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/avr -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/rx63n -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/utility -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/utility/driver -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/utility/r_byteq_v1.30 -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/utility/r_config -I/Applications/IDE4GR.app/Contents/Java/hardware/arduino/rx63n_2/cores/arduino/utility/T4_src -Wall -ffunction-sections -fno-function-cse -fsigned-char -fdata-sections -mno-balign -DTESTING=1 -DGRSAKURA -DARDUINO=100 -DCPPAPP -D__RX_LITTLE_ENDIAN__=1 -D__T4__ -O2 -flto -mlittle-endian-data -mcpu=rx600 -m64bit-doubles -c -x c++ /Users/shio/tmp.ide4gr/build2612602148285772166.tmp/Fading.cpp -o /Users/shio/tmp.ide4gr/build2612602148285772166.tmp/Fading.cpp.o
Fading.ino: In function 'loop':
Fading.ino:43:1: internal compiler error:
Illegal instruction: 4
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.kpitgnutools.com> for instructions.

のように実行されたコマンドが作業ディレクトリに作成されたソースファイル込みで表示されています。コマンドラインで上記のコマンドを実行することで問題のエラーを再試行できる筈ですが、その際にエラーが出たソースファイルを編集することで問題箇所の絞り込みはできるのではないでしょうか。

Linux や Solaris では ldd コマンドというのでダイナミックリンクされるライブラリを調べることができるらしいですが、Mac では otool というので同様のことができるらしいです。RX 用ツールチェーンから使用されてるライブラリを確認し、タイムスタンプを確認することで怪しいものの目星は付けられるのではないでしょうか。

ちなみに、前に貼ったリンクではGMP ライブラリの更新方法まで書かれていますがご確認されましたでしょうか。一応念のため書いておきます。

検索すると、

Illegal instruction: 4

↑は、古い OS 用にビルドしたバイナリを新しい OS で実行しようとすると出るもののようです。やはり動的リンクされるライブラリに問題があるのではないでしょうか。

検索すると、

Illegal instruction: 4

↑は、古い OS 用にビルドしたバイナリを新しい OS で実行しようとすると出るもののようです。やはり動的リンクされるライブラリに問題があるのではないでしょうか。