それで、私はネットサーフィンしていて、この記事につまずきました。基本的に、バージョン10以降のFreeBSDでは、Clang / LLVMを優先してGCCを廃止する予定です。
私がこれまでネットで見てきたことから、Clang / LLVMはかなり野心的なプロジェクトですが、信頼性の観点からはGCCに匹敵するものではありません。
FreeBSDがコンパイラインフラストラクチャとしてLLVMを選択している技術的な理由はありますか、それとも全体の問題は永遠のGNU / GPL対BSDライセンスに要約されていますか？
回答:
要約： GCCからClangに切り替える主な理由は、GCCのGPL v3ライセンスとFreeBSDプロジェクトの目標との非互換性です。ユーザーベースの要件だけでなく、企業投資に関する政治的な問題もあります。最後に、標準への準拠とデバッグの容易さに関して、技術的な利点が期待されます。コンパイルと実行における実際のパフォーマンスの向上は、コード固有で議論の余地があります。両方のコンパイラについてケースを作成できます。
FreeBSDとGPL： FreeBSDはGPLと不安な関係にあります。BSDライセンスの支持者は、真にフリーなソフトウェアには使用制限はないと考えています。GPLの支持者は、ソフトウェアの自由を保護するために制限が必要であり、特に、フリーソフトウェアから非フリーソフトウェアを作成する能力は、自由ではなく権力の不当な形態であると考えています。FreeBSDプロジェクトは、可能な場合、GPLの使用を避けようとします：
しかし、GPLソフトウェアの商用利用で進化する可能性がある追加の複雑さのために、可能な場合は、より緩和されたFreeBSDライセンスの下で、そのようなソフトウェアを提出物に置き換える努力をします。
FreeBSDとGPL v3の：GPL v3の明示いわゆる禁じTivo化コードの、中抜け穴GPL v2のユーザーがそれ以外の場合は法的なソフトウェア変更を許可しないように、ハードウェアの制限を可能にしました。この抜け穴を塞ぐことは、FreeBSDコミュニティの多くの人々にとって受け入れがたいステップでした。
特にGPLv2の下で現在ライセンスされているソフトウェアの大部分が現在新しいライセンスに移行した場合、アプライアンスベンダーが最も失うものが多くなります。GPLv3ソフトウェアを使用したり、ハードウェアにインストールされているソフトウェアの変更を制限したりすることはできなくなります。要するに、GPLライセンスソフトウェアの代替手段を理解することに突然興味を抱くオープンソースコンシューマーが大勢います。
GCCがGPL v3に移行したため、FreeBSDは2007年にリリースされた GCC 4.2.1（GPL v2）の使用を余儀なくされ、現在ではかなり古くなっています。古いコンパイラを実行し、修正をバックポートするという追加のメンテナンスの頭痛があっても、FreeBSDが最新のバージョンのGCCを使用するように移行しなかったという事実は、GPL v3を回避するための要件の強さのいくらかの考えを与えます。CコンパイラはFreeBSDベースの主要コンポーネントであり、「FreeBSD 10の（仮の）目標の1つはGPLフリーのベースシステムです」。
企業投資：多くの主要なオープンソースプロジェクトと同様に、FreeBSDは企業から資金提供と開発作業を受けています。AppleによるFreeBSDへの資金提供や開発の程度は簡単には発見できませんが、AppleのDarwin OSはBSD由来の実質的なカーネルコードを使用しているため、かなりの重複があります。さらに、2007年にオープンソース化されるまで、Clang自体は元々社内のAppleプロジェクトでした。企業のリソースはFreeBSDプロジェクトの重要なイネーブラーであるため、スポンサーのニーズを満たすことはおそらく重要な現実世界のドライバーです。
ユーザーベース： FreeBSDは多くの企業にとって魅力的なオープンソースオプションです。ライセンスはシンプルで制限がなく、訴訟につながる可能性が低いためです。GPL v3の登場と新しいTivoisation対策規定により、より寛容なライセンスに向けて、ベンダー主導の加速的な傾向があることが示唆されています。FreeBSDの商業エンティティに対する認識された利点は、その寛容なライセンスにあるため、GCCおよびGPL全般から遠ざかるという企業ユーザーベースからの圧力が高まっています。
GCCの問題：ライセンスとは別に、GCCの使用にはいくつかの問題があります。GCCは完全に標準に準拠しておらず、ISO標準Cにはない多くの拡張機能があります。300万行を超えるコードで、「最も複雑でフリー/オープンソースのソフトウェアプロジェクトの1つ」でもあります。この複雑さにより、ディストリビューションレベルのコード変更が困難なタスクになります。
技術的な利点： Clangには、GCCと比較していくつかの技術的な利点があります。最も注目すべきは、はるかに有益なエラーメッセージと、IDE、リファクタリング、およびソースコード分析ツール用に明示的に設計されたAPIです。ClangのWebサイトには、はるかに効率的なコンパイルとメモリ使用量を示すプロットが表示されますが、実際の結果は非常に変わりやすく、GCCのパフォーマンスとほぼ一致しています。一般に、Clangで作成されたバイナリは、同等のGCCバイナリよりも実行が遅くなります。
LLVMの使用は、GCCよりもコードのビルドが高速ですが、ほとんどの場合、GCC 4.5でビルドされたバイナリはLLVM-GCCまたはClangよりも優れたパフォーマンスを示しました...残りのテストでは、パフォーマンスはGCCのパフォーマンスに近いか十分でした後ろに。一部のテストでは、Clangで生成されたバイナリのパフォーマンスはひどいものでした。
結論：特にバイナリのパフォーマンスが不足している場合、FreeBSDのような大規模なプロジェクトをまったく新しいコンパイラツールチェーンに移行する大きなリスクを冒すために、コンパイルの効率が重要な動機となることはほとんどありません。しかし、状況は実際には持続可能ではありませんでした。1）古いGCCを実行する、2）最新のGCCに移行してプロジェクトの目標と互換性のないライセンスを使用する、または3）安定したBSDライセンスコンパイラに移行するという選択肢があります。おそらく避けられなかった。これは基本システムとディストリビューションからのサポートにのみ適用されることに注意してください。ユーザーが自分のFreeBSDボックスに最新のGCCをインストールして使用することを妨げるものは何もありません。
検討する価値のあることの1つは、ireBSDがire_and_cursesの回答に記載されているように、現在GCC 4.2.1を使用しているため、パフォーマンスの比較が4.5ではなく、4.6でさえプロジェクトに関連しないことです。したがって、あなたが尋ねるべき質問は次のとおりです。
プロジェクトで使用している古いGCCと比較して、新しいClangのパフォーマンスはどの程度向上していますか？
GCC 4.2.1でコンパイルされた同じバイナリは、新しいClangと比較してどうですか？
GCCがGPL v3に移行したため、FreeBSDはGCC 4.2.1（GPL v2）の使用を余儀なくされました。これは2007年にリリースされ、現在ではかなり古くなっています。
Clangが現在のGCCに遅れを取っているが、プロジェクトに実装されたGCCよりもまだ数年先である場合、進化するという彼らの決定は十分に正当化され、本当に刺激を受けます。
GCCはGPLv3ですが、GCCによって生成された結果のバイナリにはライセンスの制約がありませんでした。明らかに、GCCを使用して、必要なライセンスに該当するソフトウェアを構築できます。GCCに付属し、バイナリに含まれているCライブラリもライセンス不要です。http://www.gnu.org/licenses/gcc-exception-faq.html
GNU GPLv3のセクション2：
すべてのターゲットコードが適格なコンパイルプロセスによって生成された場合、ランタイムライブラリを独立したモジュールと組み合わせることによって形成されたターゲットコードの作業を伝播する許可があります。その後、独立したモジュールのライセンスに合わせて、選択した条件でそのような組み合わせを伝えることができます。
「適格」とは、コンパイルにGCCとGPL非互換ソフトウェアの両方が含まれないことを意味します。それは制限ではありません：BSDライセンスのソフトウェアは、GNU GCCを含むビルドプロセスで使用できます。
ご覧のように、上記で述べたことに反して、FreeBSD内でGCCを使用することには非互換性がないため、GCCから離れる本当のライセンス関連の理由はありません。
この変更の背後にある本当の理由は、政治的で日和見的です。
これらの事実は、FreeBSDがGCCから離れてそれを取り除く機会を作り出します。彼らは、GCCを使用してフリーまたはBSDライセンスのソフトウェアを構築することができるため、実際には法的に強制されていませんが、 「すべてのBSDライセンスソフトウェア」哲学。
license of compiler != license of end product。コンパイラーのライセンスに関する苦情は、ユーザーがライセンスを理解していない限り関係がない可能性があります。
私は専門家ではありませんが、私の理解では、Clang / LLVMはGCCよりも少ないリソースを使用し、より高速です。
http://clang.llvm.org/features.html#performance
多くのものを何度も構築する必要がある環境を実行している場合、そのパフォーマンスはエネルギーコストと時間の実際の節約に変わる可能性があります。それが本物なら。