私は、C ++ 0x標準をターゲットとしてC ++で書かれた古いコードベースの新しい管理者です。コードにはいくつかのgccとg ++の依存関係が含まれています。 CentOS 7 EOL以降、プログラムの依存関係をパッチするのが心配です。もちろんまだ4年は残っているが計画を立てた方がいいのではないか…。
このコードベースの多くの問題の1つは、コードが次に依存することです。GNUパス。ライブラリは2006年以降は上流にとどまらず、新しいソフトウェアはBoostコルーチンまたは同様の動作を使用して同等の動作を達成するか、pthreadを使用する必要があります。
私はPthまたはPth自体の使用がバージョン2.17（CentOS 7ではうまく機能します）と2.27（Ubuntu 18.04ではglibcの中断）で導入されたバグや互換性のない変更に依存すると100％確信しています。私たちのソフトウェア）。完全なソースコードとデバッグシンボルがあっても、この問題はデバッグに非常に有害です。これは、Pthの運用モデルが継続的にスタックを破壊し、プログラムが特定のエラーモードにどのように入ったかを把握するのが難しいからです。
私は問題をglibcバージョンに分割し、glibc 2.28を使用してCentOS 8で試しました。私にとって、これは回帰ではなく意図的な変更のように見えますが、以前のバージョンとの互換性を破ります。
最近観察されたglibcの衝突はここに焦点を当てません。私はCentOS 7よりもEOLの日付が長く、CentOS 8またはUbuntu 20.04でglibc 2.17をサポートする予定のリポジトリがあるかどうか疑問に思います。
もちろん、glibc 2.17をコンパイルしてそれをバイナリに静的にリンクすることはできますが、これはもはやそのバージョンのglibcのセキュリティ更新プログラムを受け取ることができないことを意味します。ソフトウェアはパブリックインターネットからアクセスできるポートで直接リッスンするので、このアイデアはまったく気に入らない。
結局、破損を引き起こした正確なバージョンのglibcを見つけるためにgitを介して二分することができますが、それでも負担はまだ残ります。私のもの私が選択したglibcバージョンのセキュリティパッチを維持します。私がエンタープライズディストリビューションを好む理由の1つは、ABIとAPIに準拠したセキュリティアップデートを長年にわたって完全に受け取ることができるため、便利なときにアプリケーションソフトウェアの転送ポッティングをゆっくりと処理できることです。奇妙に思えるかもしれませんが、このスケジュールを2024年6月（CentOS 7セキュリティアップデートの終了）以降に延長したいと思います。
以前のバージョンですが、パッチが適用されたglibcを引き続き使用するにはどうすればよいですか？それとも良い選択肢がない場合は、今から2024年6月の時間を使って基本的な問題を解決してアップグレードする方が良いでしょうか？