LGPL、.lib、.dll、およびリンク
Libconfig（ http://www.hyperrealm.com/libconfig/ ）の変更されていないコピーを使用するプロジェクトを構築しようとしています。 libconfigはLGPLですが、自分のコードをオープンソースにしたくありません。私の理解では、LGPLは、ライブラリのソースを提供する必要がある（簡単）ことを意味し、aは、ライブラリの独自の変更バージョンを使用することを意味します。それは私を少し混乱させる後者のコンポーネントです（いくつかのナイーブについての謝罪）。
現在、私のVS2010ソリューションには私のプロジェクトとlibconfigプロジェクトがあります。 libconfigプロジェクトはdllをビルドしますが、dllの定義を取得するためにlibconfigの.libに対してプロジェクトをリンクする必要もあります（すでにヘッダーファイルをインクルードしているときに、これが必要な理由を誰かが説明できますか？）。リンクしているにもかかわらず、バイナリを実行するには、実行時に.dllファイルが存在している必要があります。
LGPLを満たすために、作成したすべての.objファイルと.libファイルを提供する必要がありますか？ .libファイルのリンクを回避する方法はありますか？ LoadLibaryとGetProcAddressを調べましたが、思ったよりもずっと複雑に見えます。
それとも、LGPLの要件をここで単純に過大評価していますか？
C++用のより寛容な別の構成ライブラリがある場合、それも私のジレンマを解決します。しかし、私は何かを見つけることができませんでした（そして、ブーストを避けたいです）。
このコンテキストでの「ライブラリの独自の修正バージョンを使用するための手段」は、ユーザーが必要に応じて、自分の代わりに独自のlibconfig.dllを使用できるようにします。動的にリンクすることにより、この要件を満たしています。ファイルを置き換えるだけです。代わりに静的にリンクした場合、実行するためにlibconfig.dllは必要ありませんが、またを提供する必要がありますオブジェクトファイルとビルドスクリプト。
Libconfigプロジェクトはdllをビルドしますが、dllの定義を取得するためにlibconfigの.libに対してプロジェクトをリンクする必要もあります（すでにヘッダーファイルをインクルードしているときに、これが必要な理由を誰かが説明できますか？）。
簡単に言うと、ヘッダーファイルはガイドを提供します呼び出し方法ライブラリからの関数、つまり、関数の名前は何ですか、どのパラメーターが受け入れますか、呼び出し規約は何ですか、何ですか戻り型です。一方、Libファイルはコンパイラにガイドを提供します見つける場所関数、つまりlibconfig.dllライブラリの相対アドレス0x123456（または関数の相対アドレス）にあるため、そのコンパイラは、関数にバインドするためのコードを生成できます。
.libファイルのリンクを回避する方法はありますか？
はい、LoadLibraryを使用してDLLを動的にロードし、関数の名前をパラメータとしてGetProcAddressを使用して関数のアドレスを検索できます。次に、ポインタを使用して関数を呼び出します。この場合、 libファイルが必要ですが、関数のプロトタイプを見つけるヘッダーファイルが必要です。