gentooシステムでgccをアップグレードした後に再構築するパッケージ
Gentooシステムでgccをアップグレードした後、どのパッケージを再構築する必要がありますか？実行するのに十分ですか
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
同様に提案されたように このFAQのPerlの場合 ？
TL; DR
Gentooユーザーとしてこれについて別の見方をしています。 「Let the System Decide」というピーターフのアプローチには同意しますが、 [〜＃〜] abi [〜＃〜] 更新に関しては同意しません。 ABI更新は、動作の大きな変化となる場合があります。 GCC 4.7の場合、ABIの変更は新しいC++ 11標準の採用であり、これもピーターフが指摘しました。
これが私がこの答えを書いた理由です。私は標準的な中毒者です。約4種類のブラウザーがあり、特定のブラウザーでのみサポートされていたHTMLのタグが多すぎるときに、私はWebの世界で始めました。当時、これらのタグはすべて混乱を増し、IMOは作業を難しくしました。 C++はこれと同じ理由で標準化されています。つまり、私が書いたコードをコンパイルしたり、あなたが書いたコードをコンパイルしたりできます。基準に従わないことを選択した場合、共有する自由が失われます。
C++ 98は13年間承認された標準です。 C++ 11は、2011年にISO委員会によって承認され、GCC 4.7に完全に統合されました。 現在のISOステータス と 新しいISO標準 を参照してください。
Gentooユーザーとして特権を感じるべき理由
ソースベースのディストリビューションのユーザーとして、私たちはパッケージを使用する前にコンパイルするので、パッケージの将来の振る舞いを形作るユニークな機会があります。したがって、その機会に備えるために、新しいコンパイラーに更新するときに、次のコマンドを実行する必要があると思います。
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
最初のパススルーシステムは、古いコンパイラーを使用して、新しいコンパイラーとその依存関係を構築します。システムの2番目のパスは、新しいコンパイラを再構築し、新しいコンパイラとの依存関係です。具体的には、ビルドチェーンパッケージも更新された場合に ビルドチェーン が新しいコンパイラの新機能を利用できるようにこれを行います...一部の人々は2番目のパススルーシステムを置き換えますワールドセットでは、どのパッケージが新しい標準を既にサポートしているかがわからないので、これはやり過ぎだと思いますが、ビルドチェーンが正常に動作することを望んでいます。
これを少なくともシステムセットに対して実行すると、ローリングリリースを使用するため、新しい標準に対してコンパイルするすべてのパッケージをテストする準備が整います。このようにして、-std=c++11 to CXXFLAGSビルドチェーンの更新後、破損をテストし、バグを直接Bugzillaに送信するか、次の単純な理由で実際の開発者の上流に送信できます。
ねえ、あなたのパッケージは新しいC++標準を使って何とか何とか壊れて、ビルドログを添付しました。
標準がより広く採用されるようになり、古い標準が段階的に廃止されるので、開発者には準備の時間があるので、私はこれを開発者の礼儀と考えます。開発者が何百ものバグを受け取った場合、標準が段階的に廃止されるまで待機していたため、開発者側の騒動を想像してみてください。
実際のパッケージメンテナーは、それぞれのユーザーコミュニティがパッチまたはアップデートを使用する前に仲介者として存在するため、私が知っている他のディストリビューションではこの方法を使用できません。メンテナはいますが、ローカルポーテージツリーを使用することもできます。
バウンティリクエストに投稿された洞察に満ちた考えについて
皆さんが私の洞察に満ちたよく考え抜かれた答えを気に入っているので、賞金が投稿されたかどうかはわかりませんが、報奨金の試みとして、私はあなたの洞察に満ちたよく考え抜かれた賞金の申し出に答えようとします。まず、ソースベースのディストリビューションのユーザーとして、私はドットを接続するものはあなたの賞金リクエストで要求したすべてのものであると私は強く信じています。誰かが優れたコーダーになることはできますが、ソフトウェアには細心の注意を払います。同じように、ソフトウェアに細心の注意を払っているくだらないコーダーである人々がいます。
ここに来る前は、 Gentooフォーラム で熱心なポスターをやりました。やっとここに来たとき、誰もがある程度の才能を持っていることに気づきました。貢献の違いを生むのは、彼らがそれをどうするかを選ぶことです。私たちの中には優秀なライター（私ではない）がいるため、あるプロジェクトに貢献したいが、コードを書いたりできない、バグを修正したりする場合は、優秀なライターが優れたドキュメントや優れたWiki記事を書くことができることを忘れないでください。 。
標準は別の理由で存在します：コミュニティでは、特定のルールがそのメンバーに期待されています。ここでもその説明に従ってください。修正、パッチ、拡張などを提出し、標準がない場合、パッチは私が重要だと考える状況でのみ機能します。つまり、whizbangコンパイラ2.0を使用していて、パッチがwhizbangコンパイラ1.0に対してビルドされている場合、失敗します。努力はコミュニティのためのものなので、コミュニティはほとんどの状況ですべてが機能することを期待しています。したがって、すべてのユーザーにコンパイラ2へのアップグレードを強制する代わりに、標準で規定することができます。
このパッケージは、Whizbang Compiler 1.0との下位互換性を許可することを選択します
このようにして、開発者として、くだらないコーダーであろうとなかろうと、私はコンパイラバージョン1.0を使用するか、少なくともテストする必要があることを知っています。一方、ユーザーとしては、やりたいことを選ぶことができます。私が不満を感じている場合は、バグを送信するか、「このソフトウェアはがらくたである！」という極端な例でパッチを要求しても、何もできません。とにかく、標準が作成されているため、ユーザーと開発者は標準を理解しています。
ギャップを埋めるには、ユーザーの側で何らかの形でアクションを実行します。そのためには、私や他のユーザーにコメントを求めたすべてのことが必要です。ユーザーコミュニティに依存する必要があり、すべてのフォームの才能がそのギャップを埋める必要があります。あなたが貢献ユーザーの1人になることを選択した場合、私はあなたを称賛します。非アクティブにすることを選択した場合は、修正が必要な場合、アクティブなものが入力を必要とすることを覚えておいてください。だから私はあなたに言っています、バグを提出すること、またはドキュメントを更新する必要があることを私たちに知らせてください、そして私たちが失礼な場合は私たちに教えてください、またはあなたの専門分野を見つけるまで他の誰かを見つけてください。
このトピックに関連する他の興味深い読書
コンパイラのアップグレードの種類によって大きく異なります。それが充実している場合、すべてが再コンパイルされているはずです*） コンパイラによるABIの変更の可能性があるためです。多くの場合それは必要ありませんが、パッケージがC++ 11のようなものに依存している場合、問題が発生する可能性があります。 GCC 4.7でのABI変更に関するGentooニュース または GCC bugzilla 。
*） 「再コンパイル」に重点を置いていることに注意してください。Cコンパイラを変更したので、PythonまたはPerlアプリケーション）を再コンパイル（読み取り再構築）することは明らかに意味がありません。ネイティブコンポーネントがまあ（それはまあまあ）。