問題タブ [dynamic-linking]

使用するすべての Qt モジュールが実行可能ファイルと同じディレクトリに含まれるように、qt アプリをビルドしました。アプリのビルドに使用したマシンで動作し、アプリの現在のディレクトリを除くすべての共有ライブラリを削除して、これをテストしました。ldd を実行すると、現在のディレクトリでこれらのライブラリを探し、実行可能ファイルを単独で配置すると、実行可能ファイルを開くことができないことが示されます。これで問題はありませんが、このディレクトリをホスト マシンに転送しても、これらのライブラリが見つかりません。何が問題なのですか？

共有ライブラリ/dllから関数を呼び出す最も簡単で安全な方法は何ですか？私は主にLinuxでこれを行うことに興味がありますが、プラットフォームに依存しない方法があればもっと良いでしょう。

fooユーザーが自分のバージョンを共有ライブラリにコンパイルした場合に、次の作業を行う方法を示すサンプルコードを誰かが提供できますか？

ところで、私は共有lib（foo.so）をコンパイルする方法を知っています、実行時にそれをロードする簡単な方法を知る必要があります。

.soファイルとして提供されているコンパイル済みライブラリを使用しようとしています。

このファイルは、いくつかの書店に対して動的にリンクされています。

残念ながら、Debian / squeezeには、libstdc++-libc6.1-1.so。*ファイルはありません。libstdc++6パッケージによって提供されるlibstdc++。so。*ファイルのみ。

（ln -sを使用して）libstdc++-libc6.1-1.so.2をlibstdc++。so.6ファイルにリンクしようとしました。これは機能しません。このライブラリを使用して.oファイルをldしようとすると、シンボルのバッチが不足しているようです。

あなたならどうしますか ？これらのシンボルがエクスポートされているライブラリをどのように見つけることができますか？

アプリで使用しているサードパーティのOSXdylibがあり、その作成者に簡単にアクセスできません。-flat_namespaceにリンクされているかどうかを確認したいと思います。それは可能ですか？もしそうなら、どのように？

I'm debugging an issue on OS X that only occurs when the application is started from the dock. It does not happen when the app is started from the command line. What is the difference between the two scenarios? The code I'm working with is a c++ based bundled plug-in being loaded in a third party app. I've attached to the process with GDB in both scenarios and the only difference I can see is that a couple of extra dylibs are loaded in the process when running from the command line and that the base address of my library is slightly different in the two scenarios. I've tried changing my linkage to -prebind and/or -bind_at_load to no avail.

MacOSX 10.6でPython拡張機能を構築し、それをいくつかのフレームワーク（i386のみ）に対してリンクしようとしています。distutilsとExtensionオブジェクトを使用してsetup.pyファイルを作成しました。

フレームワークに対してリンクするように注文すると、LDFLAGSenvvarは次のようになります。

拡張モジュールのドキュメントに「framework」キーワードが見つからなかったため、代わりにextra_link_argsキーワードを使用しました。

すべてが正常にコンパイルおよびリンクされています。extra_link_argsから-framework行を削除すると、期待どおりにリンカーが失敗します。これがpythonsetup.pyビルドによって生成された最後の2行です：

残念ながら、私が作成した.soは、このフレームワークによって提供されるいくつかのシンボルを見つけることができません。リンクされたフレームワークをotoolで確認してみました。それらのどれも表示されていません。

私の投稿の上部に記載されているLDFLAGSを使用してg++とlddで作成されたテストバイナリで実行されたotoolの出力があります。この例では、-frameworkは機能しました。

この問題は、リンク手順の「-undefineddynamic_lookup」フラグにリンクできますか？Googleで見つけた数行のドキュメントに少し混乱しています。

乾杯、

ctypes を介して Python から呼び出したい関数を含むライブラリを C で書いています。

私はこれを別のライブラリで成功させましたが、そのライブラリには非常にバニラの依存関係 (つまり、、、、、)しかありfstreamませんでした。私が取り組んでいる他のライブラリには、より複雑な依存関係があります。mathmallocstdiostdlib

たとえば、 を使用してみますfftw3。テストとして、以下を含む単純な.cppファイルをコンパイルしてみます。

私はそれを次のようにコンパイルします：

これはすべて機能します。.cpp次に、次を含む別のファイルでテストします。

結果：

これは完全に合理的です。次に試します：

すごい！しかし今、ライブラリを ctypes でロードしようとすると:

同じ問題ですが、ctypesで解決する方法がわかりません。私は成功せずにさまざまなことを試しましたが、この時点でかなり行き詰まっています。

Linux は初めてですが、ダイナミック ライブラリを使用してコンパイルしているときに、segmentationfault エラーが発生します。

私は2つのファイルを持っています

ctest1.c

ctest2.c

次のコマンドを使用して、両方のファイルを libtest.so という名前の共有ライブラリにコンパイルしました

そして、このライブラリによってエクスポートされた関数を使用する別のプログラム prog.c を作成しました。

prog.c

そして、次のコマンドで実行可能ファイルをビルドしたとき

gcc -Wall prog.c -L. -o プログラム

しかし、生成された実行可能ファイルを実行すると、SegmentationFault エラーが発生します。

ldd で prog のヘッダーを確認すると、次のように表示されます

linux-vdso.so.1 => (0x00007f99dff000) libc.so.6 => /lib64/libc.so.6 (0x0007feeaa8c1000) /lib64/ld-linux-x86-64.so.2 (0x00007feeaac1c000)

誰かが何が問題なのか教えてもらえますか

Ubuntu9.10x86_64にバイナリLinuxアプリケーションをインストールしていました。アプリには、はるかに古いカーネル用にコンパイルされた古いバージョンのgzip（1.2.4）が付属しています。

このプログラムを実行できませんでした。私が試した場合、これは起こりました：

lddも同様にこのバイナリに不満を持っていました：

私は興味があります：この問題の最も可能性の高い原因は何ですか？破損したファイル？または、はるかに古い{kernel、libc、...}用に構築されているためにバイナリの非互換性がありますか？

nosの提案によると、次の出力がありstrace ./gzipます。

これがの出力ですreadelf -a ./gzip：

フルスクリーンの後処理効果を追加するプログラムがあります。私はプログラムのソースを持っていません（開発者がデバッグシンボルのコピー、.map形式を送ってくれましたが、それは独自のものです）。エフェクトのコードが記述されて機能していますが、問題はありません。

私の問題は今、2つをリンクすることです。

これまでに2つの方法を試しました。

迂回を使用して、元のプログラムのインポートテーブルを変更します。これはうまく機能し、安定していることが保証されていますが、私が話したユーザーはそれに慣れておらず、（アーカイブを抽出する以外に）インストールする必要があり、Detoursでプログラムにパッチを適用することが条件の下で有効かどうか疑問がありますEULAの。したがって、そのオプションはありません。

もう1つのオプションは、従来のDLL置換です。OpenGL（opengl32.dll）をラップしましたが、システムコピーの代わりにDLLをロードするプログラムが必要です（プログラムフォルダーに正しい名前でドロップするだけです。簡単です）。

次に、Cgフレームワークとランタイム（OpenGLに依存）およびその他のいくつかのものをロードするためにDLLが必要です。Cgがロードされると、Cg関数を呼び出すいくつかの関数が呼び出され、スタックオーバーフローや無限ループが発生する傾向があります。Cg DLLをサブディレクトリに含めてもその機能を使用できるようにする必要があります（DLLインポートテーブルがサブディレクトリ内のDLLを指すようにすることが可能かどうかはわかりません）、または動的にリンクする必要があります（これは私がdビルドプロセスを単純化するためだけに、そうしないでください）、システムのファイルを参照するように強制するものです（私のカスタム置換ではありません）。

チェーン全体は次のとおりです。プログラムはDLLA（opengl32.dllという名前）をロードします。DLL AはCg.dllをロードし、動的にsysdir / opengl32.dllにリンクします（GetProcAddress）。DLL Aではなく、sysdir/opengl32.dllも参照するためにCg.dllが必要になりました。

これはどのように行われますか？ 編集： GetProcAddressを使用せずにこれを簡単に行うにはどうすればよいですか？他に何も機能しない場合、私はそれにフォールバックするつもりですが、可能であれば、むしろしたくありません。

Edit2： MSDNドキュメントで関数SetDllDirectoryに出くわしました（まったく関係のない検索で）。一見、それは私が必要としているもののように見えます。そうですか、それとも私は誤解していますか？（今すぐテストするためにオフ）

Edit3：少し違うやり方でこの問題を解決しました。OpenGL32.dllを削除する代わりに、DLLの名前をDInput.dllに変更しました。120をはるかに超える関数（プログラム、Cg、およびGLEWの場合）ではなく1つの関数をエクスポートする必要があるという利点があるだけでなく、関数が再び実行されることを心配する必要はありません（通常どおりOpenGLにリンクできます） 。傍受する必要のある通話に入るには、迂回路を使用しています。全体として、それははるかにうまく機能します。ただし、この質問は依然として興味深い問題です（そして、将来、クレイジーなことをしようとしている他の人にとって役立つことを願っています）。どちらの答えも良いので、どちらを選ぶべきかまだわかりません...