gccGentooシステムをアップグレードした後、どのパッケージを再構築する必要がありますか？走るのに十分ですか？
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
提案どおりこのFAQでPerlについて？
ベストアンサー1
長い話を短く
Gentooユーザーとして、私はこれについて異なる視点を持っています。私はPeterevの「システムが決定する」アプローチに同意しますが、同意しません。ABI直す。 ABI の更新は時々動作の重要な変化です。 GCC 4.7を例にとると、ABIの変更は新しいC++11標準を採用することだとPeterphも指摘しました。
それで私はこの答えを書きました。私は標準的な常習者です。私が最初にWeb世界に入門したとき、ブラウザは4つほどあり、HTMLのかなりの数のタグは特定のブラウザでのみサポートされました。当時、これらのすべてのラベルは混乱を加重し、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ケースCXXFLAGSをテストし、バグをバグまたは直接開発者の上流に直接送信できます。理由は次のとおりです。
こんにちは、あなたのパッケージなどが新しいC ++標準に違反しました。ビルドログを添付しました。
標準がより広く採用され、既存の標準が段階的に廃止されるにつれて、準備する時間が生じたので、これは開発者のための礼儀だと思います。標準が段階的に廃止されるのを待ってから何百ものバグを受け取った場合は、開発者が感じる混乱を想像してください。
私が知っている限り、そのユーザーコミュニティにパッチやアップデートが提供される前に実際のパッケージマネージャがブローカーとして存在するため、他のディストリビューションはこのアプローチを使用しません。私たちには管理者がいますが、ローカルPortageツリーを使用することもできます。
賞金リクエストの投稿に関する洞察力のある考え
皆さんが私の洞察力と思いやりのある回答が好きで、私が賞金を投稿するかどうかはわかりませんが、私は賞金を得るためにあなたの洞察力と思慮深い賞金提案に答えるように努力します。まず、ソースベースのディストリビューションのユーザーとして、私はポイントをつなぐことが賞金の要求に必要なものだと確信しています。誰かが素晴らしいプログラマーになることができますが、ソフトウェアに興味を持っているのは不便かもしれません。同様に、不都合なプログラマーがソフトウェアに深い関心を持つ人々がいます。
ここに来る前は、熱心なポスター愛好家でした。Gentooフォーラム。ここに来始めたとき、ついに誰もが活用できるある程度の才能があることに気づきました。貢献度の違いを作ることは、彼らがそれを使用することを選択したものです。私たちのいくつかは素晴らしい作家です（私ではありません）。したがって、プロジェクトに貢献したいのですが、コードを書いたり、バグを修正したりできない場合は、優れた作家は素晴らしいドキュメントや素晴らしいWiki記事を書くことができることを覚えておいてください。
この規格は別の理由で存在します。コミュニティでは、メンバーは特定の規則に従う必要があります。。その声明はここでも続きます。修正、パッチ、改良などを提出しましたが、標準がなければ重要だと思う場合にのみパッチが機能します。つまり、whizbang コンパイラ 2.0 を使用し、そのパッチが whizbang コンパイラ 1.0 用にビルドされている場合は失敗します。 。これはコミュニティのためのものであり、コミュニティはほとんどの場合すべてが機能したいので、すべてのユーザーがコンパイラ2にアップグレードすることを強制するのではなく、標準に割り当てることができます。
このパッケージオプションは、Whizbang Compiler 1.0との下位互換性を可能にします。
これにより、開発者として、私は不都合なコーダであるかどうかにかかわらず、コンパイラバージョン1.0を使用するか、少なくともテストする必要があることを知っています。一方、私はユーザーとして自分がやりたいことを選択できます。満足できない場合は、バグを報告してパッチを請求したり、「このソフトウェアはゴミです！」という極端な措置を講じたり、何もしないことがあります。それにもかかわらず、ユーザーと開発者は標準が作成されたので、標準を理解します。
ギャップを解消するには、ユーザーの何らかの形のアクションが必要です。そのためには、私と他の人にコメントするように求めたすべてのことが必要です。私たちは、このギャップを解消するために、ユーザーコミュニティとそのさまざまな形態の才能に頼る必要があります。貢献しているユーザーの一人になることを選択した場合は、拍手をお送りします。非アクティブ状態を選択した人の場合は、問題を解決するにはアクティブな人の意見が必要であることに注意してください。だから、バグを報告することを恥じないでください。失礼な場合は、文書を更新する必要があると言ったり、自分の専門分野を見つけるまで他の人を探してください。