アカウント名:
パスワード:
ユーザーとしては、Linux向けアプリケーションのコンパイルや移植で問題がないのかが心配です。FreeBSDって、とても使いやすやすいOSだと思います。GPLフリーになることで商業利用が進んで一般向けに普及が進むのか、ライブラリなどのLinuxとの互換性低下で移植などに支障が出るのかが、が問題ですよね。
clangってコンパイラーはじめて聞いたので早速試してみたけど、Makefile の CC=gcc を clangに書き換えただけで適当にダメ元で試したら、意外と動くのが多くて驚いた。
__attrubute__(aligned((16))); みたいなGCC方言が入っててもコンパイル通ったけど、インラインアセンブラでSSEのアライメント依存の命令を使ってるのだと正常に動作しないのがあった。
__sync_fetch_などのアトミック操作のGCC方言も普通に使われてるけど、これは動いた。
よくわからないけど、予想以上に多くのソースが無難に通った。あとコンパイル速度がGCCより倍ぐらい速く感じた。
あとvoid main() がエラーになる。警告じゃなくて。f(int a){ return a; } だと警告になる。gccよりくちうるさい。
GCC方言使ってても通るってのが意外すぎて驚いた。アップルすごい。
LLVMなんだから、
・コンパイルの速度は速くなる・バイナリのサイズは小さくなる・実行時の速度は遅くなる
のは、原理的に当たり前では？MacはGCCを4.2で止めているから、世代的な意味で速度でもいい勝負になるかもってだけで。ただ、中間コードのせいでバイナリ互換性がでたりすると恐ろしいとは思うけど、現状では開発でclangを使ってチューンと製品用にはgccを使うのがいいと思う。
clangはただのC/C++/Obj-Cコンパイラですから、GCCなどと同じ.oファイル吐きますよ。元のコメントに「Makefile の CC=gcc を clangに書き換えただけ」と書いてあることから、リンクには（ldを呼び出す）gccが使われていることと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Linux向けアプリのコンパイル (スコア:2)
ユーザーとしては、Linux向けアプリケーションのコンパイルや移植で問題がないのかが心配です。
FreeBSDって、とても使いやすやすいOSだと思います。
GPLフリーになることで商業利用が進んで一般向けに普及が進むのか、ライブラリなどのLinuxとの互換性低下で移植などに支障が出るのかが、が問題ですよね。
Re: (スコア:3, 興味深い)
clangってコンパイラーはじめて聞いたので早速試してみたけど、
Makefile の CC=gcc を clangに書き換えただけで適当にダメ元で試したら、
意外と動くのが多くて驚いた。
__attrubute__(aligned((16))); みたいなGCC方言が入っててもコンパイル通ったけど、インラインアセンブラでSSEのアライメント依存の命令を使ってるのだと正常に動作しないのがあった。
__sync_fetch_などのアトミック操作のGCC方言も普通に使われてるけど、これは動いた。
よくわからないけど、予想以上に多くのソースが無難に通った。
あとコンパイル速度がGCCより倍ぐらい速く感じた。
あとvoid main() がエラーになる。警告じゃなくて。
f(int a){ return a; } だと警告になる。gccよりくちうるさい。
GCC方言使ってても通るってのが意外すぎて驚いた。アップルすごい。
Re: (スコア:1)
LLVMなんだから、
・コンパイルの速度は速くなる
・バイナリのサイズは小さくなる
・実行時の速度は遅くなる
のは、原理的に当たり前では？MacはGCCを4.2で止めているから、世代的な意味で速度でもいい勝負になるかもってだけで。ただ、中間コードのせいでバイナリ互換性がでたりすると恐ろしいとは思うけど、現状では開発でclangを使ってチューンと製品用にはgccを使うのがいいと思う。
Re:Linux向けアプリのコンパイル (スコア:1)
clangはただのC/C++/Obj-Cコンパイラですから、GCCなどと同じ.oファイル吐きますよ。元のコメントに「Makefile の CC=gcc を clangに書き換えただけ」と書いてあることから、リンクには（ldを呼び出す）gccが使われていることと思います。