共有ライブラリのバージョン依存問題を解決したい

Question

Qtをソースからビルドしてみたところ、Qtの共有ライブラリが下のような状態になっていて、Qtアプリが起動しませんでした。

root@beaglebone:/tmp# ldd /opt/qt-arm/lib/libQtCore.so
/opt/qt-arm/lib/libQtCore.so: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by /opt/qt-arm/lib/libQtCore.so)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6c53000)
: : : : :
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6aff000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6a19000)

libc.soとしてGLIBC_2.15を要求しているようですが、そういう理解であっていますよね。
一方、そのlibcの方はというと、

root@beaglebone:# ls -la /lib/arm-linux-gnueabihf/libc.so.6
lrwxrwxrwx 1 root root 12 Feb 22 20:29 /lib/arm-linux-gnueabihf/libc.so.6 -> libc-2.13.so
root@beaglebone:# file /lib/arm-linux-gnueabihf/libc-2.13.so
/lib/arm-linux-gnueabihf/libc-2.13.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x56ee5330c584ca115f4e3bbc3e6d58ca34c6aea1, for GNU/Linux 2.6.26, stripped

このようにlibc.so.6の実体であるlibc-2.13.soはバージョン2.13のようです。これは現在のディストリビューション(debian)では既に最新となっていて、これ以上新しいのはapt-getできませんでした。
また、GLIBCを勝手に変更するとシステム自体に問題が出ることがあると聞いたので、GLIBCを2.15に上げるのではなく、libQtCore.so.4が要求するバージョンを2.13以下となるようにしたいです。

とりあえずQtが動くようにする暫定パッチを作りたいのですが、どういう仕組みでQtがGLIBC 2.15を要求しているのかが分かりませんでした。GLIBCの特定のバージョンを要求する方法とはどいうものなのでしょうか？ソースコード中のpragmaやコンパイルオプションで指定するものなのでしょうか？Qtのソースツリーを適当なキーワード（_GLIBC_MINOR_など）でgrepしてみたのですが、そういう記述は見つけられませんでした。

識者の方、アドバイスをお願いします。

ちなみに、Qtソースは4.8.6で、開発ホスト=x86-Ubuntu／ターゲット=arm-linuxでクロスコンパイルしています。

Answer 1

libc.soとしてGLIBC_2.15

という認識に間違いはないと思います。
んー…クロスコンパイルに使っている、glibc (のヘッダ)のバージョンが何かというのが気になります。
私なら、開発ホスト上に、ターゲット用の glibc がどこかに展開されているはずで、そのバージョンを下げてみる…という手段をとることを考えます。詳細まで、すぐに分からないです。ごめんなさい。

Comments

[退会済みユーザー]

アドバイスありがとうございます。

いただいたコメントを拝見して、はたと思いました。
"Qtが特定のバージョン（以上）を要求している"のではなくて、"開発用ホストでクロスビルドしたときに参照したターゲット用glibcと同じバージョンを、ターゲット側にもインストールしておく必要がある"ということなんですね。勉強になりました。

ご提案いただいた方法（開発ホストのglibcを下げる）ことはまだ試せていませんが、開発ホストに入っていたglibcなどのライブラリをターゲットに転送して、Qtアプリを起動するときだけそのライブラリを参照するようにしたところ、Qtアプリが起動することを確認できました。
ご提案の方法がこれから試してみたいと思います。
ありがとうございました。

[takotakot]

あ、そういえばそういう手がありましたね…私も聞いて思いました(コメントを書いたときは、忘れていました)。
「開発ホストに入っていたglibcなどのライブラリをターゲットに転送」で動くならこれで何の問題もありません。バージョンアップで挙動が変わるライブラリなんかは、この手で対応することがよくありますね。

どのように「開発ホストに入っていたglibcなどのライブラリをターゲットに転送して、Qtアプリを起動するときだけそのライブラリを参照するように」したのかを、お時間があれば記して頂ければ、似たような問題で困った人の助けになるかと思います。(環境変数でいけるケースだったのかな)

[退会済みユーザー]

シェルのプロンプトから一行で

LD_LIBRARY_PATH=(転送したライブラリのパス) (起動したいアプリ) [オプション]

とすれば、このアプリを起動するときだけ↑のライブラリパスを優先的に探してくれるようです。

間違ってもシェルの環境変数に、export LD_LIBRARY_PATH=(ライブラリパス)とはしないことですね。私は操作ミスでそうなってしまい、ほとんどの基本コマンドがSegmentation faultで落ちるようになってしまい「やっちまった！」と焦りましたが、何の事はないLD_LIBRARY_PATHを解除すれば直りました。

あと、私は怖くって試せませんが、ld.so.cacheを更新するとそれこそ酷いことになりそうですね。