以下のコメントで Praetorian が指摘したように、devtoolset を使用すると、この回答で最初に説明した問題が実際に解決されます。答えを修正しました。
これらのライブラリのバージョン 4.4 と 4.7 の不一致により、プログラムにバグが発生するリスクはありますか?
はい。新しい libstdc++.so に対してリンクしてから、古いものに対して実行しようとすることは、100% サポートされていません。プログラム内のオブジェクトまたは使用するライブラリが GCC 4.7 でコンパイルされ、4.7の libstdc++.so にリンクされている場合、実行時に 4.7 (またはそれ以降) の libstdc++.so を使用する必要があります。おそらく実行すらされませんが、実行された場合、非互換性によるサイレント バグが発生する可能性があります。ただし、GCC 4.7 の libstdc++.so にリンクしていないため、これは問題ではありません。以下を参照してください。
GCC 4.7 のバージョンの libc と libstdc++ を静的にリンクすることで回避できますか?
1）「GCC 4.7のlibcバージョン」などはないため、libstdc ++に対してのみこれを行う必要があります。glibc は GCC とは完全に別のプロジェクトです。GCC 4.7 を使用している場合、別の libc は使用していません。CentOS 6.4 のシステム libc を引き続き使用しています。(余談ですが、glibc を静的にリンクすることは glibc のメンテナーによって強く推奨されており、glibc の一部の機能は静的にリンクされていると機能しないことに注意してください。)
2) libstdc++ を静的にリンクすると問題を回避できますが、その必要はありません。Red Hat Developer Toolset (devtoolset) がとにかくそれを行うからです。devtoolset の全体的なポイントは、新しい GCC と新しい libstdc++ を使用できるようにすることですが、新しい libstdc++ ライブラリに実行時の依存関係を作成する必要はありません。コンパイルされた実行可能ファイルは、devtoolset がインストールされていないシステムであっても、RHEL/CentOS に常に存在する libstdc++.so のシステム バージョンのみを必要とします。(devtoolset が行うことは、すべての新しい libstdc++ 機能を静的ライブラリにパッケージ化しlibstdc++_nonshared.a、システム libstdc++.so に存在しないすべての部分が静的にリンクされ、他のすべてがシステム libstdc++.so から取得されるように呼び出されることです)。
devtoolset を使用していない場合、libstdc++ を静的にリンクする代わりの別のオプションは、新しい libstdc++.so をコードとともに出荷し、それが最初に見つかるようにすることです (たとえば、新しい libstdc++.so を参照する RPATH にコードをリンクすることによって)。 ）。しかし、devtoolset ではそれは必要ありません。
または、私のコードが動的にロードする他のライブラリが、システム全体の GCC 4.4 パッケージによって提供される古い libc / libstdc++ を取得する場合、他の問題に備えていますか?
常に古い libstdc++ を使用しているため、devtoolset を使用する場合、このような問題は発生せず、競合が発生することはありません。