問題タブ [dynamic-linking]

このようなグローバル変数を定義する静的ライブラリlibStaticがあります

ヘッダファイルlibStatic/globals.h:

コードファイルlibStatic/globals.cpp:

DLL libDynamicと実行可能ランナーは、このグローバル変数を使用しています。さらに、libDynamic実行時にランナーLoadLibrary()にリンクされます（ 、 、および作品を介しGetProcAddress()て...）

これにより、ランナーのヒープに1回、 libDynamicのヒープにglobvar1回、2回作成されることになることを理解していますが、これはもちろん非常に望ましくありません。

このあたりに良いところはありますか？libDynamicとrunnerが同じものを使用していることを確認するにはどうすればよいglobvarですか?

博士号取得のために高速カメラからのデータを処理するプログラムを作成しています。事業。このカメラには、カメラと通信して画像を取得するための、Linux 上の .so ファイル形式の SDK が付属しています。前述のように、大量のデータを配信する高速カメラです (1 分間に数 GB)。この量のデータを処理するために、SDK には非常に便利なスプール機能があり、データを DMA 経由でハード ドライブに直接スプールします。FITS ファイルは、天文学で使用されるヘッダー付きの生のバイナリ形式です。この関数は、小さな C プログラムを作成し、.so ファイルをリンクして、この方法でスプール関数を呼び出すと正常に機能します。しかし、.so ファイルを ctypes でラップして Python から関数を呼び出すと、スプール関数を除くすべての関数が動作します。スプール関数を呼び出すと、エラーは返されませんが、スプールされたデータ ファイルが文字化けします。ファイルの形式は正しいのですが、全フレームの半分が 0 です。私の世界では、.so ファイル内の関数が、自分の小さな C プログラムまたは python から呼び出されたプログラムに応じて異なる動作をする必要があることは意味がありません。さまざまなプログラムから .so を呼び出すときの違いについて、何か手がかりはありますか?

私はどんな提案にもとても感謝しています

カメラは商用ですが、一部のドライバーは GPL 化されて利用可能ですが、少し複雑です。（残念ながら、スプール機能ではないようです）カメラのヘンデル用のPythonのオブジェクトがあります。

クラスの冒頭には次のように書かれています。

関連する関数は次のとおりです。

対応するヘッダーには次のように書かれています。

カメラを実行するコードは次のようになります。

私は、ソフトウェアの同じ部分が 1 つの実行可能ファイルといくつかの DLL に分割されている小さな製品を数多く見てきました。これらの DLL は、他の誰かによって作成された単なる共有ライブラリではなく、このソフトウェア専用に作成されたライブラリです。同じ開発チーム。(ここでは、何百もの DLL を必要とし、それらを他の製品と広く共有するだけの大規模な製品について話しているのではありません。)

コードをいくつかの部分に分割し、それぞれを個別の DLL にコンパイルすることは、開発者の観点からは良いことだと理解しています。だということだ：

• 開発者が 1 つのプロジェクトを変更した場合、このプロジェクトと依存するプロジェクトのみを再コンパイルする必要があり、これによりはるかに高速になる可能性があります。
• プロジェクトはチーム内の 1 人の開発者が行うことができますが、他の開発者はコードに介入することなく、提供されたインターフェイスを使用するだけです。
• ソフトウェアの自動更新は、サーバーへの影響が少なく、高速になる場合があります。

しかし、エンドユーザーはどうでしょうか? すべてをグループ化できるのに、1 つの EXE と複数の DLL で構成されるソフトウェアを提供するのは、単に悪いことではないでしょうか? 結局：

• ユーザーは、それらのファイルが何なのか、そしてなぜそれらが自分のハードディスクのメモリをいっぱいにするのかさえ理解していないかもしれません。
• ユーザーは、USB フラッシュ ドライブにプログラムを保存するなど、プログラムを移動したい場合があります。1 つの大きな実行可能ファイルがあると作業が簡単になります。
• ほとんどのウイルス対策ソフトウェアは、各 DLL をチェックします。1 つの実行可能ファイルをチェックする方が、小さな実行可能ファイルと多数のライブラリをチェックするよりもはるかに高速です。
• DLL を使用すると、いくつかの処理が遅くなります (たとえば、.NET Framework では、「適切な」ライブラリを見つけて、署名されているかどうかを確認する必要があります)。
• DLL が削除されたり、不適切なバージョンに置き換えられたりするとどうなりますか? すべてのプログラムはこれを処理しますか? それとも、何が問題なのかを説明することさえせずにクラッシュしますか?
• 1 つの大きな実行可能ファイルを持つことには、他にもいくつかの利点があります。

小規模/中規模のプログラムの場合、エンド ユーザーの観点からは、1 つの大きな実行可能ファイルを提供する方がよいのではないでしょうか? もしそうなら、それを簡単に実行できるツールがないのはなぜですか (たとえば、ソリューション全体を 1 つの実行可能ファイルにコンパイルする一般的な IDE に統合された魔法のツールは、もちろん毎回ではなく、オンデマンドまたは展開中に)。

これは、すべての CSS ファイルまたはすべての JavaScript ファイルをユーザー向けの 1 つの大きなファイルに入れることにいくらか似ています。複数のファイルを持つことは、開発者にとってはるかにスマートで保守が容易ですが、Web サイトの各ページを数十ではなく 2 つのファイルにリンクすると、パフォーマンスが最適化されます。同じように、CSS スプライトはデザイナーにとっては厄介なものです。なぜなら、CSS スプライトはより多くの作業を必要とするからです。しかし、ユーザーの観点からはより優れています。

アプリに静的にリンクされた Boost を使用していますが、今度は Boost Test を外部テスト ランナーで使用したいと考えています。これには、必要なBOOST_TEST_DYN_LINK定義を使用して、テスト自体が Boost.Test と動的にリンクする必要があります。

これは問題になるのでしょうか、それとも Boost Test のリンク方法は、他の Boost ライブラリのリンク方法とはまったく関係ありませんか?

Visual Studio 2008には、2つのプロジェクトを含むソリューションがあります。1つは.dllで、もう1つは.dllを呼び出すコマンドラインアプリケーションです。

ファイルの1つ（ "ast.c"）を削除してから直接追加すると、次のエラーが発生します。

このエラーを修正するにはどうすればよいですか？

エラー22エラーLNK2019：未解決の外部シンボル "__declspec（dllimport）int __cdecl ast_get_int_value（struct ast_node *、void *）"（__ imp_？ast_get_int_value @@ YAHPAUast_node @@ PAX @ Z）関数 "double __cdecl d_low（struct ast_ struct ast_node *、struct ast_node *、struct ast_node *、void *） "（？d_low @@ YANPAUast_node @@ 000PAX @ Z）main.obj main

C++ コードのライブラリを「ホットプラグ」しようとしています。この手法を Linux/Mac/Windows 間のクロス プラットフォームで機能させることに興味があります。基本的に、すべての呼び出し可能なインターフェイスを定義するメイン プログラム #include "StateMachine.h" が必要です。次に、実行時と実行中に StateMachineLibrary.a をロードおよびアンロードして、アプリケーションで異なるステート マシンを使用するようにします。

私が考えているのは、このコンパイルされたコードを自分のmallocされたメモリにロードし、そのメモリに関数ポインタを作成するラッパーを書くようなことでしょうか?

動機は、私のプロジェクトのステート マシンの部分が頻繁に変更され、再コンパイルが必要になることです。また、メイン アプリがさまざまなステート マシンをロードして実行し続けることができるようにします。いくつかの懸念があるため、Luaスクリプトなどの代わりに「ホットプラグ可能な」ライブラリを使用したいと考えているため、代替手段としてすでに検討されていることを考慮してください。

実行可能ファイルを共有する場合、その実行可能ファイルを作成するために使用されるライブラリについて本当に心配する必要がありますか? exeを実行する必要があるときではなく、exeを生成するときに考慮する必要があるようです。ちょっと興味があるんだけど。心配する必要はないと確信していますが、確認のためにこの質問をしたかったのです。後悔するよりも安全であること。

ダイナミックライブラリのパスは-install_name、@ rpath、および@loader_pathを使用して修正する必要があるため、DYLD_LIBRARY_PATHの使用を推奨しない記事をいくつか読みました。

LinuxとMacOSXの両方で実行されるプログラムを作成するという点では、Mac OS XのDYLD_LIBRARY_PATHは、LinuxのLD_LIBRARY_PATHとまったく同じように機能します。そして、-install_nameと@rpathを持たない（ほぼ）同じmakeファイルを共有できます。

• Mac OS XでDYLD_LIBRARY_PATHを使用しても大丈夫ですか？
• バイナリがダイナミックライブラリを見つけられない場合のMacOSXのダイナミックライブラリ検索アルゴリズムは何ですか？現在のディレクトリ->DYLD_LIBRARY_PATHディレクトリ...？

iPhone SDK 4.0 にアップグレードし、静的ライブラリとアプリを再コンパイルしました。iOS 3.1.3 を搭載したデバイスで実行すると (配置ターゲット 3.0 を使用)、次のように表示されます。

このブログ投稿を見つけましたが、それ以外のアドバイスはないようです

1. 4.2 の代わりに gcc 4.0 を使用してみてください。

2. SDK 4.0 で修正されているはずです。

彼が指しているコードは SDK 4.0で修正されたようです (そして、この動作を示す最小限のアプリの彼の例は私にとっては問題なく動作します) が、まだこのエラーが発生しています。

サードパーティが Objective-C プラグインを作成できるようにするために、 Viennaの拡張に取り組んでいますが、64 ビット モードで実行している場合にのみランタイム リンカーの問題が発生します (32 ビット モードではすべて正常に動作するように見えます)。 . 私のプラグイン SynkPlugin は、Vienna.app の次のコードによって読み込まれます。

コンソール出力に、次のエラー メッセージが表示されます。

このエラーは、32 ビット モードではなく、64 ビット モードで実行している場合にのみ発生します。Vienna と SynkPlugin はどちらも「標準の 32/64 ユニバーサル」設定でコンパイルされており、SynkPlugin には追加のリンカ フラグ「-undefined dynamic_lookup」があります。これらのクラスのコードを独自のバイナリにコンパイルします。

Stack Overflow でのこのエラーに関するその他の参照は、iPhone/iPod Touch と iPad の間の UIKit の違いに関係しています。これらの場合、実際にはフレームワークに iPhone/iPod Touch のクラスがありません。私の場合、Vienna.app は 32 ビット バージョンと同じコードから構築されているため、その中に Article クラスが含まれていることは確かです。

誰もこのようなエラーを見たことがありますか? 詳細情報をどこで探すべきかについて何か提案はありますか? ありがとう。