問題タブ [static-libraries]

実行可能ファイル foo.exe が静的ライブラリに基づいて構築され、この foo.exe の 6 つのインスタンスがマシン上で同時に実行されているとします。RAM の読み書き部分を除いてすべてのコードは同じ (読み取り専用部分) であるため、パフォーマンスを向上させるために RAM 内のこれら 6 つのインスタンス間で共有することはありますか?

上記の foo.exe が代わりに共有ライブラリを使用する場合、これらの共有ライブラリのインスタンスが 1 つしか実行されていないインスタンスが 6 つあるにもかかわらず、RAM に存在することはわかっています。

Linux で共有ライブラリをインストールするには、makefile を使用する方法を考え出すことに午前中を費やしました。

それで結構です。これで、共有オブジェクトとそれへの一対のソフト リンクができました。そのうちの 1 つは ldconfig によって作成され、もう 1 つは私によって作成されました。

これで、ライブラリを静的ライブラリとして構築することもできます。

/usr/lib を確認すると、そこにある .a ファイルが...そこにあることがわかります。シンボリック リンク、ファイル名のバージョンとリリース番号の配置はありません。

共有オブジェクトを配置するのと同じように、シンボリック リンクを使用してスタティック ライブラリを配置する必要がありますか?それとも、装飾のない静的ライブラリを /usr/local/lib に配置するのが実際の慣習なのでしょうか?

64 ビット Linux で mysql-python を mysql クライアント ライブラリに静的にリンクしようとした人はいますか?

参照: mysql-python: Mac OS X で完全にスタンドアロンの _mysql.so をビルドしますか?

Linux でアプリケーションの静的にリンクされたバイナリ バージョンを配布しています。しかし、2.4 カーネルを搭載したシステムでは、起動時にセグメンテーション違反が発生し、「FATAL: カーネルが古すぎます」というメッセージが表示されます。

2.4 カーネルでバージョンを簡単に起動して実行するにはどうすればよいですか? 必要なライブラリのいくつかは、2003 年頃の古い Linux ディストリビューションでも利用できません。古いカーネルを簡単にターゲットにできる apt-get インストールなどはありますか?

静的ライブラリと共有ライブラリの議論では、共有ライブラリが重複を排除し、全体的なディスク容量を削減するとよく耳にします。しかし、最近のLinuxディストリビューションでは、共有ライブラリが実際にどれだけのディスク容量を節約できるのでしょうか。すべてのプログラムが静的ライブラリを使用してコンパイルされた場合、どれだけ多くのスペースが必要になりますか？Ubuntuなどの典型的なデスクトップLinuxディストリビューションの数を減らした人はいますか？利用可能な統計はありますか？

補遺：

すべての回答は有益であり、感謝されていますが、彼らは私の質問に答えようとするのではなく、撃ち落とすようでした。Kalebは正しい方向に進んでいましたが、ディスクスペースではなくメモリスペースの数値を計算することを選択しました（私の質問はディスクスペースに関するものでした）。

プログラムは、使用する静的ライブラリの部分に対してのみ「支払い」を行うため、すべての静的ライブラリとすべての共有ライブラリのディスク容量の違いを定量的に知ることは事実上不可能のようです。

答えるのは事実上不可能だと気付いた今、私は自分の質問を捨てたくなっています。ただし、有益な回答を保持するために、ここに残しておきます。

SOが答えを選ぶように私をしつこくするのをやめるために、私は最も人気のあるものを選びます（たとえそれが質問を回避したとしても）。

動的にリンクされたライブラリが、オーバーロードされたオペレーター delete を呼び出しているのに、オペレーター new を呼び出していないことに問題があります。私のexeは次のようになります。

そして、静的にリンクされたライブラリがあり、グローバルなオーバーロードされた演算子と、問題を引き起こしている動的にリンクされたライブラリがあります。基本的に何が起こるかというと、dynLib::Type 型には、コンストラクターに要素を追加する std::vector が含まれています。したがって、タイプは次のようになります

func() が呼び出されると、Type の新しいインスタンスが作成され、値によって渡されてから t に割り当てられます。そこで動作する operator= は、std::vector にもその operator= を介してコピーします。これは、コンストラクターに要素が既に追加されているため、t の古い std::vector で deallocate を呼び出します。この割り当て解除呼び出しは、最終的にオペレーター delete を呼び出します。問題は、私の演算子 new が呼び出されなかったため、完全に異なるメモリ空間でポインタを削除していることです (メモリ ロギングがこれを示しています)。

今、私はおそらく何かが欠けているだけです。上記のクラス A は dynLib::Type オブジェクトを保持しているため、(スタティック ライブラリからの) new 演算子がリンクされる前に構築される可能性があります。それは可能ですか？構成された dynLib::Type のコンストラクターがどの時点で呼び出されるかはよくわかりません。動的ライブラリはデフォルトの stl アロケータを使用するため、ファンキーなことは何もしません。

exeに Type クラスを含めるだけで、動的にリンクされたライブラリを使用せずに同じ状況を再現しようとしました。ただし、これは問題の原因ではないため、リンクの順序に関係があるに違いないと私は信じています。

私のグループが、ソース ファイルの約 90% を共有する一連の大規模なアプリケーションを構築する方法を再編成しようとしています。現在、これらのアプリケーションは、私たちの管理下にない外部リンクのものを除いて、ライブラリを一切使用せずに構築されています。アプリケーションは同じ共通ソース ファイルを使用します (同じ .h/.cpp ファイルの 5 つのバージョンを維持していません) が、これらはどの共通ライブラリにも組み込まれていません。そのため、現時点では、バージョンをリリースするたびに、アプリケーションごとに同じコードを何度も作成する代償を払っています。私には、これはライブラリを使用して共有コードをキャプチャし、ビルド時間を短縮するための最有力候補のように思えます。DLL を使用するオプションがないため、アプローチは静的ライブラリを使用することです。

この仕事に取り組むためのヒントを教えてください。私は静的ライブラリの作成/整理の経験が限られているため、整理/落とし穴に対する基本的な提案でも大歓迎です。多分良い本の推薦でさえありますか？

各アプリケーションが共通に共有するファイルのサブセット全体を見つけることによって、簡単な演習を行いました。概念実証として、これらのファイルを単一の「Common Monster」スタティック ライブラリに配置しました。この単一の静的ライブラリを使用して完全なアプリケーションをビルドすると、すべてのアプリケーションのビルド時間が確実に改善されますが、このままにしておく必要がありますか? この形式のライブラリの目的はあまり焦点が絞られておらず、モジュール化の怠惰な試みのように見えます。これらのアプリケーションの開発は進行中であり、この設定が今後さらに問題を引き起こすのではないかと心配しています。

.libファイルと.objファイルはどのように相互に関連していますか？彼らの目的は何ですか？.libは単なる.objファイルのコレクションですか？もしそうなら、.objは.lib内に保存され、.objは不要になりますか？

重複の可能性:
Windows の「リソース ファイル」に相当する Linux はありますか?

gcc ツールチェーンを使用して C ソースとリンクするためにリソースをスタティック ライブラリに埋め込む方法を見つけようとしています。リソースが埋め込まれた Windows DLL に相当します。これは Linux の静的ライブラリで実行できますか?

要するに、たとえば、これ cat someresourcedata.txt > mylib.aを実行し、それを参照するコンパイル済みの C コードとリンクできるようにしますmylib.a。

アイデアや提案はありますか？

多くの共有ライブラリと静的ライブラリに内部的にリンクしている共有ライブラリを作成しようとしています。私の場合、私の共有ライブラリには static lib が含まれていません。それが正しいかどうか、または静的ライブラリを共有ライブラリに変換してからリンクを行う必要があるかどうかを知りたいです。

共有 lib とともに静的ライブラリを追加できるようにする makefile フラグがあることを知る必要があります。

提案してください 。