5

私はいくつかのコードをコンパイルしていますが、さまざまな理由で静的に実行しています。私のUbuntu 12.04 / gcc 4.6.3マシンでは、コンパイルは正常に実行され、完全に静的です。

> ldd mycode
    not a dynamic executable

ここまでは順調ですね。しかし、gcc 4.5.3 を実行する別のマシン、Scientific Linux 5 システムでも実行する必要があります。何らかの理由で、ldd にはいくつかの動的ライブラリが残っています。

> ldd mycode
    linux-vdso.so.1 =>  (0x00007fffd75fd000)
    libstdc++.so.6 => /usr/local/swift/gcc-4.5.3/lib64/libstdc++.so.6 (0x00002b4bafab2000)
    libm.so.6 => /lib64/libm.so.6 (0x000000398ca00000)
    libc.so.6 => /lib64/libc.so.6 (0x000000398c600000)
    /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000000398c200000)
    libgcc_s.so.1 => /usr/local/swift/gcc-4.5.3/lib64/libgcc_s.so.1 (0x00002b4bafdb8000)

それ自体は問題ありません。コードは正常にコンパイルおよびリンクされ、ldd からわかるように、すべての依存関係が解決されています。ただし、SL マシンで実行しようとすると失敗します。

> ./mycode
  /lib/ld64.so.1: bad ELF interpreter: No such file or directory

したがって、私が見る限り/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2、ldd が実行しても、何らかの理由で実行時にリンクが解決されません。もちろん、ルート アクセス権があるマシンでは、ld-linux-x84..blah から /lib/ld64.so.1 へのシンボリック リンクを作成することでこれを解決できますが、これはかなり単純な解決策であり、適用できません。それを私たちのクラスターに。全体を動的にコンパイルすると問題なく動作しますが、これは、回避したかった多数のマシンに対してコンパイルしているすべてのサードパーティ ライブラリをインストールすることを意味します。最後に、私がコンパイルするすべての依存関係は、別のプロジェクトでも使用され、cmake でコンパイルされます。その場合、問題はありません。ldd は実際に、呼び出しではなく /lib64/ld-linux...blah を直接リストします。 /lib/ld64.so に。

それで - なぜこれが起こっているのですか？コードをコンパイルしてリンクし、ldd しても問題ないのに、実行できないのはなぜですか? どんなアイデアでも大歓迎です！

4

2 に答える 2

6

わかりました、私は最終的にこれをクラックしたと思います。基本的には、cmake によって渡されるリンカー引数であり、静的なものと動的なものの厄介な組み合わせでしたが、次の行を CMakeLists.txt に追加すると修正されました。

SET_TARGET_PROPERTIES (mytarget PROPERTIES LINK_SEARCH_START_STATIC 1)
SET_TARGET_PROPERTIES (mytarget PROPERTIES LINK_SEARCH_END_STATIC 1)
于 2014-08-05T13:16:38.737 に答える