5

プロジェクトで、私の同僚はアプリにリンクされた liba.a などの静的ライブラリを作成します。

liba.a で、彼は libc malloc() を所有者のバージョンに上書きします。

app にもリンクされている共有ライブラリ libs.so を作成します。

問題は、libs.so が app にリンクされている場合、libs.so で使用される malloc() が、標準の libc.so のものではなく、liba.a のものになるため、問題が発生することです。

次に、libc.a を libs.so に静的にリンクしたいので、gcc に -static -shared -fPIC フラグを使用しました。

しかし、私は常に arm-2012.03/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.3/../../../../arm-none-linux-gnueabi/bin を取得します/ld: arm-2012.03/bin/../arm-none-linux-gnueabi/libc/usr/lib/libc.a(dl-tsd.o)(.text+0x14): R_ARM_TLS_LE32 再配置は共有オブジェクトで許可されていません.

誰かがそれについて考えていますか？

よろしくお願いします。

4

1 に答える 1

2

共有ライブラリに入るコードはコンパイルする必要があり-fPIC、静的ライブラリのコードはそうではないため、できません。もしそれができたとしても、結果の実行可能ファイルは libc と何度もリンクされてしまい、とにかく壊れやすく、遅かれ早かれクラッシュする可能性があるため、とにかく実行しないでください。したがって：

しないでください。動的ライブラリはシステム ライブラリに動的にリンクする必要があり、動的ライブラリにリンクする実行可能ファイルもシステム ライブラリを動的にリンクする必要があります。

また、LGPL は動的にリンクされたコードのみを除外するため、非 GPL アプリケーションに対して GNU libc を静的にリンクすることは違法であることを思い出してください。これは、ソースが利用できない可能性がある実行可能ファイルを再コンパイルせずに、ライブラリのバグ修正を許可することを目的としています。Linux では、依存する実行可能ファイルを再コンパイルせずに共有ライブラリをバグ修正バージョンにアップグレードするのが一般的です。libc 開発者はその方法を知っています。

于 2012-09-13T08:34:38.807 に答える