升級 Fedora 版本時，在建構原生軟體方面會出現哪些類型的問題，有哪些解決方案？
我做了很多軟體測試，這需要我從原始碼建構許多不同的項目。我最近從 31 升級到 Fedora 33，基本上，我遇到了一組問題，這些問題涉及由於“缺少”依賴項而無法執行我之前建構的軟體，和/或當我嘗試建構軟體時，我得到包或庫失去的錯誤，主要是在執行之後，
./configure或者make，很多時候，它們確實不是，當然也不是我故意刪除的。其他時候，對包的更新（例如 Python 3.6 -> 3.9）會導致某些腳本出現問題，等等……有時它讓我感到困惑（除了那個 python 問題）的原因是，我實際上從未刪除過許多庫，而且似乎無論出於何種原因，它們不再被辨識，所以我必須手動顯示它們所在的建構系統，或者只是重新安裝依賴項，等等……
升級 Fedora 或其他 Linux 發行版後，是否有解決此類問題的一般建議？我想這有點普遍，雖然我當然可以逐個解決每個單獨的問題，但我會考慮這是一個集體問題，並且隨著我繼續我的 Linux 之旅，我想變得更擅長解決這個問題，因為我在未來升級。
從原始碼編譯任何重要的軟體都可能是一項複雜的任務，儘管現在有相當多的自動化來隱藏大部分細節。但是當過程中出現問題時，您需要能夠理解該過程以有效地排除故障。
不幸的是，在我看來，對失敗的編譯過程進行故障排除的知識和技能越來越多地被理解為“只有實際的軟體開發人員才能擁有的東西”，而實際上它對測試人員來說也是非常必要的，有時對系統管理員也非常有用。事實上，開源軟體的基本思想假設每個人都應該能夠重新編譯一個軟體包，如果他們願意的話。
當
./configure抱怨缺少庫時，通常是在尋找該庫的 -devel 包。
./configure實際上是一個 shell 腳本，它執行許多測試來查找和驗證編譯軟體包的先決條件。它由autoconf工具包生成，用於簡化使原始碼包可在多種硬體架構和類 unix 作業系統上編譯的工作。有時，庫開發項目或 Linux 發行版可能會對開發標頭檔（
*.h文件）在/usr/include/. 例如，舊版本可能將它們直接放在 下/usr/include/，而新版本可能將它們放在/usr/include/library_name/子目錄下。如果庫開發人員在原始碼級別進行了向後不兼容的更改，則可能需要包含庫版本號，以便發行版可以支持庫的舊版本/usr/include/library_name/和新版本/usr/include/library_name2。如果此類更改比autoconf用於為軟體包創建./configure腳本的版本更新，它可能無法自動檢測新位置。
autoconf並不完善，還有其他機制可以補充或替代。另一個常見的問題是pkg-config：每個支持它的庫包都將在其-devel包（或等效項）中包含一個*.pc文件，該文件記錄重要的編譯器選項、依賴關係和其他在建構軟體以使用相關庫時很重要的資訊。該
make步驟通常需要實際的庫包及其-devel包都存在。make當一個軟體包使用.編譯子步驟可能只需要包
*.h提供的文件-devel，但連結子步驟需要存在實際的庫包。如果您需要為 OS 主要版本 X 編譯的某些軟體在 OS 主要版本 (X+n) 上執行，您可能會遇到共享庫的問題：
- 庫經歷了向後不兼容的更改
- 庫以不同方式打包以解決名稱衝突或其他問題
- 舊庫已從發行版中完全刪除，現在由不同的庫提供該功能，或者完全以另一種方式提供。
要解決此類問題，您可能必須找到軟體實際需要的舊庫，將它們放置在通常不會搜尋庫的某個目錄中，然後使用使用環境變數的包裝腳本啟動舊程序，例如
LD_LIBRARY_PATH指定僅為該應用程序的庫的自定義搜尋路徑。有關可以更改應用程序在執行時查找共享庫的方式的操作的更多詳細資訊，請參見ld.so(8)手冊頁，尤其是其章節。ENVIRONMENT這樣，我仍然可以在目前的 Debian 10 系統上執行Sid Meier 的 Alpha Centauri（版權所有 1999）的 Linux 版本。不會太破舊，我會說。