在 gentoo 系統上升級 gcc 後要重建的包
gcc在 gentoo 系統上升級後應該重建哪些軟體包？是否足以執行# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`如本常見問題解答中 perl 的建議類似？
TL; 博士
作為 Gentoo 使用者，我對此有不同的看法。雖然我同意 peterph 的“讓系統決定”的方法，但我不同意ABI更新。ABI 更新有時是行為的重大轉變。就 GCC 4.7 而言，ABI 變化是採用了新的 C++11 標準，peterph 也指出了這一點。
這就是我寫這個答案的原因。我是個標準迷。當我開始接觸網路世界時，大約有 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第一次通過系統使用舊編譯器建構新編譯器及其依賴項。第二次通過系統重建新編譯器及其與新編譯器的依賴關係。具體來說，我們希望這樣做，以便我們的建構鏈利用新編譯器的新功能，如果建構鏈包也已更新……有些人用世界集替換了第二個直通系統，雖然我發現這太過分了，因為我們不知道哪些軟體包已經支持新標準，但我們確實希望我們的建構鍊錶現得正常。
至少對系統集執行此操作，使我們準備好根據新標準測試我們編譯的每個包，因為我們使用滾動發布。這樣，在更新建構鏈後添加
-std=c++11toCXXFLAGS允許我們測試損壞，並能夠將錯誤直接送出給我們的 bugzilla 或上游給實際的開發人員，原因很簡單：嘿，你的包 blah blah 使用新的 C++ 標準破壞了，我附上了我的建構日誌。
我認為這是對開發人員的一種禮貌，因為隨著標準被更廣泛地採用，並且舊標準被逐步淘汰，他們現在有時間準備。想像一下，如果開發人員收到數百個錯誤，他或她的騷動，因為他或她一直等到標準被淘汰……
據我所知，沒有其他發行版可以使用此方法，因為在相應使用者社區可以使用更新檔或更新之前，實際的包維護者作為中間人存在。我們確實有維護者，但我們也有能力使用本地的 portage 樹。
關於賞金請求中發表的有見地的想法
我不知道是否發布了賞金，因為你們都喜歡我有見地、深思熟慮的答案，但在嘗試賞金時，我會嘗試回答你有見地、深思熟慮的賞金提供。首先，讓我回應說，作為基於源的發行版的使用者，我堅信連接這些點的是您在賞金請求中要求的所有內容。有人可能是一名出色的編碼員，但對軟體卻有蹩腳的照顧。同樣，有些人是蹩腳的程序員，卻對軟體非常關心。
在我來到這里之前，我是Gentoo 論壇的狂熱海報。當我開始來到這裡時，我終於意識到，每個人都有一些他們可以使用的天賦。正是他們選擇使用它來做出貢獻的差異。我們中的一些人是偉大的作家（不是我），所以如果你想為某個項目做出貢獻，但你不會或不能編寫程式碼或修復錯誤，請記住偉大的作家可以寫出偉大的文件或偉大的 Wiki 文章.
該標準的存在還有另一個原因：在社區中，期望其成員有某些規則。在此處也遵循該聲明。如果我送出了修復、更新檔、增強等並且沒有標準，則該更新檔僅在我認為重要的情況下有效，即如果我使用 whizbang 編譯器 2.0，並且該更新檔是針對 whizbang 編譯器 1.0 建構的，它將失敗。由於努力是為了一個社區，社區希望一切在大多數情況下都能正常工作，所以我可以在標準中規定，而不是強迫所有使用者升級到編譯器 2：
這個包選擇允許向後兼容 Whizbang Compiler 1.0
通過這種方式，無論是否作為開發人員，無論是否是蹩腳的編碼人員，我都知道我必須使用 Compiler Version 1.0 或至少對其進行測試。另一方面，作為使用者，我可以選擇我想做的事情。如果我不滿意，我可以通過送出錯誤或“這個軟體是垃圾！”的另一個極端來請求更新檔，並且什麼都不做。無論如何，使用者和開發人員都理解該標準，因為它已經編寫好了。
彌合差距需要使用者採取某種形式的行動，這需要您要求我和其他人發表評論的所有事情，我們必須依靠使用者社區和他們各種形式的才能彌合這一差距。如果您選擇成為貢獻使用者之一，我為您鼓掌。對於那些選擇不活躍的人，請記住，如果您想要修復某些東西，活躍的人需要您的輸入。所以我告訴你，不要羞於送出錯誤，或者告訴我們需要更新文件，如果我們粗魯，請告訴我們，或者找其他人，直到你找到你的專業領域。
與此主題相關的其他有趣閱讀