タグ付けされた質問 「static-linking」

LGPLでは、プログラムがLGPLで編集されたライブラリを使用する場合、ユーザーはプログラムを別のバージョンのライブラリと再リンクできる必要があります。 ... d）次のいずれかを実行します。 0）このライセンスの条件の下で最小限の対応するソース、および適切な形式で対応するアプリケーションコードを伝え、ユーザーがアプリケーションをリンクバージョンの修正バージョンと再結合または再リンクして、対応するソースを伝えるためにGNU GPLのセクション6で指定された方法で、変更された結合作業。 1）適切な共有ライブラリメカニズムを使用して、ライブラリとリンクします。適切なメカニズムは、（a）ユーザーのコンピューターシステムに既に存在するライブラリのコピーを実行時に使用し、（b）リンクバージョンとインターフェイス互換性のあるライブラリの修正バージョンで適切に動作するメカニズムです。 ... ただし、場合によっては、これによりかなりの困難が生じる可能性があります。特に、Haskellプログラムはほとんど常に静的にコンパイルされます。さらに、コンパイラはモジュール間の最適化を行うため、コードの一部を取り出して別のものに置き換えることはできません。したがって、この条件を満たすことは非常に困難です。（Haskell Wikiのこのリンクを参照してください。） 動的リンクが解決策になりますが、多くの場合、これは不可能です。例えば： プラットフォームによっては、動的リンクがまったくない場合があります。 一部の言語には、動的リンクの可能性がありません。または、モジュールをマルチプラットフォームにすることはできません。 場合によっては、動的リンクによって重要な最適化が妨げられます。これが深刻な問題になることはめったにないと思いますが、Haskellのような言語では、パフォーマンスの損失がかなり大きくなる可能性があります。 したがって、再リンクの可能性を必要としない標準のLGPLのようなライセンスを探しています（そして、それはユーザーに与えられた少しの自由を取り除くことを理解しています）。wxWidgetsなど、一部のプロジェクトではLGPLの独自の変更を使用しています。しかし、私はむしろ、いくつかの法律の専門家によってチェックされ、（L）GPLと互換性のある、より公式な標準ライセンスを使用したいと考えています。そのようなものはありますか？ （また、LGPLのそのような修正の予期しない結果があるかどうかを知りたいと思います。）

21 licensing  lgpl  static-linking 

Appleは、iOS用に動的にロードされるライブラリ（フレームワークと呼ばれる）を作成する機能を持っていることは明らかです。アプリ開発者は静的ライブラリを作成する機能しか持っていないか、せいぜい、実際に静的ライブラリをロードしているときにフレームワークをロードしているとXcodeをだまします。これは、偽のフレームワークの作成として知られています。しかし、動的ローディングの利点はありません。 アプリ開発者からの動的なフレームワークを保持するためのAppleの理由は何ですか？開発者は繊細なリンカーフラグやオープンソースライブラリの依存関係チェーンに依存する必要がないため、外部ライブラリの使用がかなり容易になるようです。 一般的な理由はセキュリティだと思います。なぜAppleはiOSではなくOSXでそれを許可するのですか？セキュリティも要件ではありませんか？ 編集：これはiOS 8からは関係なくなりました。Appleは動的フレームワークのサポートを追加しました。

11 ios  frameworks  apple  static-linking  dynamic-linking 

私はQTで働いています。 静的ライブラリは別の静的ライブラリに依存できますか？（静的ライブラリは別の静的ライブラリをリンクすることで作成されます） はいの場合、lib2にリンクした後、生成されたlib（lib1）にlib2のすべてのコードが含まれない可能性はありますか？ 私のQtプロジェクトでは、複数のライブラリに依存する静的ライブラリを使用しています。すべてのライブラリ（プロジェクト内のすべてのヘッダーを含む）を追加する必要がありましたが、コードに必要なのは1つのlib（およびそのクラスの1つの.h）だけです。 シナリオを説明してください。

11 c++  qt  static-linking 

Javaの世界では、それが時々問題となるようですが、C ++はどうですか？異なる解決策はありますか？ 誰かが特定のOSのC ++ライブラリを同じライブラリの異なるバージョンで置き換えることができるという事実について考えていましたが、私のコードが何をしているかを理解するためのデバッグシンボルでいっぱいです。標準または一般的なライブラリを使用するのは良いことですか？ これは、Windowsの一部のdllライブラリがそのライブラリの「デバッグバージョン」に置き換えられた場合にも発生する可能性があります。静的コンパイルを優先する方が良いですか？商用アプリケーションでは、アプリのコアとしてすべてを静的にコンパイルし、ほとんどの場合、dll（一般に動的ライブラリ）を使用して、海賊版対策ソリューションなどのサードパーティのテクノロジーを提供しています（多くのゲームでこれを確認しています） ）、GUIライブラリ（Qtのような）、OSライブラリなど 静的コンパイルは、Javaの世界における難読化と同等ですか？より良い意味で、それはあなたのコードを保護するための最良で最も手頃なソリューションですか？

11 c++  obfuscation  dynamic-linking  static-linking 

SOに関するこの質問から、私はそれを読みました： 独自のソースコード+ LGPLソースコード 静的にリンク： どちらもLGPLとしてリリースする必要があります。 または、ユーザーがアプリケーションを別のバージョンのLGPLソースコードに再リンクできるようにするすべてを提供します。この場合、他の要件は動的にリンクされた場合と同じです。 したがって、オブジェクトファイルを提供するだけで、LGPLライブラリを独自のコードアプリケーションに静的にリンクするという点でLGPLを満たすのに十分であるように思えます。実行可能ファイルは静的にリンクされていますが、オブジェクトファイルを提供すると、エンドユーザーはアプリケーションを再コンパイルして、異なるバージョンのライブラリにリンクできます。 これは正しいですか、正しくない場合は、なぜですか？

9 lgpl  static-linking 

ここにシナリオがあります： libA.soとlibB.soは両方とも同じSTLに静的にリンクします。 libA.soには、std :: stringを返すパブリックAPIがあります。 libB.soはこの関数を呼び出し、文字列のコピーを受け取ります。 文字列のlibB.soのコピーがスコープ外になると、文字列のデストラクタが呼び出されます。 コピーされた文字列を解放しようとするアプリケーションセグメントフォールト。 このように静的にリンクすることは悪いことを他の場所で読んだことがありますが、なぜそれが悪いのかをもっと理解したいと思います。上記のシーケンスがクラッシュする理由を誰かが説明できますか？

8 c++  libraries  stl  static-linking