☰

Fedora バージョンをアップグレードする際に、基本ソフトウェアのビルドでどのような問題が発生する可能性がありますか？解決策は何ですか？ [閉鎖]

tag-icon • tag-icon fedora compiling software-updates dist-upgrade
Fedora バージョンをアップグレードする際に、基本ソフトウェアのビルドでどのような問題が発生する可能性がありますか？解決策は何ですか？ [閉鎖]

私は多くのソフトウェアテストを実行しているので、ソースからさまざまなプロジェクトを構築する必要があります。私は最近31からFedora 33にアップグレードしましたが、本質的に「欠落している」依存関係のために以前に構築したソフトウェアを実行できない、またはソフトウェアを構築しようとしたときにエラーが発生することに関連する一連の問題に直面しています。パッケージまたはライブラリがありません。ほとんどの場合、実行後./configureまたはmake多くの時間が経過した後、実際には意図的に削除されませんでした。それ以外の場合は、パッケージの更新（Python 3.6 - > 3.9など）によって特定のスクリプトなどに問題が発生する可能性があります。

時々混乱するのは、（Pythonの問題に加えて）実際に多くのライブラリを削除せず、何らかの理由でライブラリが認識されなくなったため、そのライブラリを含むビルドシステムを手動で表示または再インストールする必要があることです。依存関係など...

Fedoraまたは他のLinuxディストリビューションをアップグレードした後、この種の問題を解決するための一般的な推奨事項はありますか？私はこれがやや一般的だと思います。できるもちろん、それぞれの個々の問題をケースバイケースで扱います。これを集約的な問題と見なし、Linuxの旅を続けながら、今後のアップグレードでこの問題をよりよく解決できることを願っています。

ベストアンサー1

ソースコードから重要でないソフトウェアをコンパイルするのは複雑な作業になるかもしれませんが、現在、ほとんどの詳細を隠す自動化された技術がかなりあります。ただし、プロセスで問題が発生した場合、効果的に問題を解決するには、プロセスを理解できる必要があります。

残念ながら、失敗したコンパイルプロセスの問題を解決する知識と技術は、ますます「実際のソフトウェア開発者だけが持っているもの」と理解されているようです。実際にはテスターに​​も当てはまります。非常に必要であり、時にはシステム管理者にとって非常に便利です。実際、オープンソースソフトウェアの基本的なアイデアは次のように想定されています。みんな必要に応じてパッケージを再コンパイルできる必要があります。

./configureライブラリが不足していると文句を言うとき、通常、実際に必要なライブラリを探している場合は、次のようになります。このライブラリの-develパッケージ。

./configure基本的に、パッケージをコンパイルするための前提条件を見つけて検証するために複数のテストを実行するシェルスクリプトです。これはautoconf、さまざまなハードウェアアーキテクチャやUNIXに似たオペレーティングシステムでソースコードパッケージのコンパイルを簡素化するためのツールキットによって生成されます。

時には、ライブラリ開発プロジェクトまたはLinuxディストリビューションで開発ヘッダー（ファイル*.h）を/usr/include/。ライブラリ開発者がソースレベルで以前のバージョンと互換性のない変更を実行している場合は、ディストリビューションが以前のバージョンや最新バージョンのライブラリなどをサポートできるように、ライブラリのバージョン番号を含める必要があります。これらの変更がパッケージスクリプトの生成に使用されたバージョンよりも新しい場合は、新しい場所を自動的に検出できない可能性があります。/usr/include//usr/include/library_name//usr/include/library_name//usr/include/library_name2autoconf./configure

autoconf完璧ではなく、それを補完または置き換えることができる他のメカニズムがあります。別の一般的なケースpkg-config：これをサポートするすべてのライブラリパッケージには、問題のライブラリを使用するソフトウェアを構築するときに重要なコンパイラオプション、依存関係、および動作を文書化するファイルがパッケージ（-develまたはそれに対応するもの）に含まれます。*.pc

このmakeステップでは、通常、実際のライブラリパッケージとその-develパッケージが必要です。ビルドパッケージを使用すると、makeそのパッケージのいくつかの部分は通常ソースコードからバイナリにコンパイルされます。宛先ファイルこれらの分離されたファイルは一緒にリンクされ、実行可能ファイルを形成します。

コンパイルサブステップではパッケージ*.hによって提供されるファイルのみが必要になる場合がありますが、-develリンクサブステップでは実際のライブラリパッケージが必要です。

オペレーティングシステムのメジャーバージョン（X + n）で実行するためにオペレーティングシステムのメジャーバージョンX用にコンパイルされたいくつかのソフトウェアが必要な場合、共有ライブラリの問題が発生する可能性があります。

  • ライブラリが以前のバージョンと互換性のない変更を受けました。
  • 名前の競合やその他の問題を解決するために、ライブラリは異なるパッケージになっています。
  • 以前のライブラリはディストリビューションから完全に削除され、機能は他のライブラリから提供されるか、まったく異なる方法で提供されます。

この種の問題を解決するには、ソフトウェアに実際に必要な古いライブラリを見つけて、通常はライブラリが検索されないディレクトリに配置し、環境を使用してライブラリを指定するラッパースクリプトを使用して古いプログラムを起動する必要があります。LD_LIBRARY_PATHカスタム検索パスなどの変数このアプリのみ。アプリケーションが実行時に共有ライブラリを見つける方法を変更する方法の詳細については、ld.so(8)マニュアルページ、特にその章を参照してください。ENVIRONMENT

これにより、Linuxバージョンを引き続き実行できます。シードマイヤーのアルファセンタウリ（著作権1999）現在のDebian 10システム。あんまりぼろぼろではないと言いたいです。

おすすめ記事