Windows の DLL のように共有オブジェクト ファイルを移植可能な方法で使用することは可能ですか??
Linux 用に、すぐに使用できるコンパイル済みライブラリを提供できる方法があるかどうか疑問に思っています。同様に、Windows で DLL をコンパイルし、他の Windows でも使用できます (他の Windows では使用できませんが、ほとんどの場合は使用できます)。
Linuxでそれは可能ですか？
編集：
私は目が覚めて答えを読んだところです。とても良いものもあります。
ソースコードを隠すつもりはありません。コンパイル済みですぐに使用できるライブラリを提供したいだけなので、コンパイルの経験がないユーザーは自分で行う必要はありません。
したがって、考えられるのは、できるだけ多くの異なる Linux で動作する .so ファイルを提供することです。
このライブラリは、STL および Boost ライブラリを使用して C++ で記述されています。
LSB アプリ/ライブラリ チェッカーを使用することを強くお勧めします 。次の場合は、すぐにわかります。
ここで詳細情報を入手したり、ツールをダウンロードしたりできます。実行するのは簡単です..それを解凍し、perl スクリプトを実行し、ブラウザを localhost に向けるだけです..残りはブラウザ駆動です.
このツールを使用すると、ライブラリ/アプリの LSB 認定を (両方のバージョンで) 簡単に取得でき、ディストリビューション パッケージャーの作業がはるかに簡単になります。
さらに、libtool (または類似のもの) などを使用して、ライブラリが正しくインストールされていることを確認し、DSO にリンクしたくない人のために静的オブジェクトを提供します (ほとんどのディストリビューションでライブラリが表示されるまでに時間がかかります)。 、移植可能なプログラムを書いているので、それが存在することを期待できません）そしてあなたの公開インターフェースによくコメントしてください。
ライブラリについては、Doxygenが最適です。ドキュメンテーションは非常に重要です。特定のタスクに使用するライブラリの選択に確実に影響します。
繰り返しになりますが、アプリ チェッカーをチェックしてください。移植性の問題に関するレポートが表示されます。このレポートを入手するには、ライブラリを実際に公開するのに 1 年かかります。
最後に、ライブラリを「ツリー内」に簡単にドロップできるようにしてください。これにより、ライブラリに対して静的にリンクする必要がなくなります。私が言ったように、ほとんどのディストリビューションで一般的になるまでには数年かかる可能性があります. ライブラリが一般化するまで、コードを取得して src/lib にドロップして使用する方がはるかに簡単です。ユニットテストをお願いします.TAP（何でもプロトコルをテストする）は、それを行うための優れた移植可能な方法です。あなたのライブラリをハッキングした場合、特にツリーまたは その場で変更する場合 (DSO が存在する場合) に、それを壊したかどうかを (迅速に) 知る必要があります。
コンパイルされたコードをユーザーに提供することでユーザーを支援したい場合、私が知っている最善の方法は、静的にリンクされたバイナリと、ユーザーがバイナリを実行する方法に関するドキュメントを提供することです。（これは、ソースコードを提供することに加えて行われる可能性があります。）ほとんどの静的リンクバイナリは、同じアーキテクチャのほとんどのLinuxディストリビューションで動作します（+ 32ビット（x86）静的リンクバイナリは64ビット（amd64）で動作します）。Skypeが静的にリンクされたLinuxダウンロードを提供するのも不思議ではありません。
ライブラリの質問に戻ります。Linuxで共有ライブラリを作成する専門家であり、依存関係を最小限に抑えて、共有ライブラリが新旧のバージョンを含むさまざまなLinuxディストリビューションで機能するように時間をかけている場合でも、確実に機能するようにする方法はありません。将来（たとえば、2年）。ほとんどの場合、.soファイルを維持することになります。つまり、.soファイルが新しいバージョンのLinuxディストリビューションと互換性を持つように、小さな変更を何度も繰り返します。これは長い間楽しいことではなく、生産性が大幅に低下します。ライブラリの互換性を維持するために費やす時間は、ソフトウェアの機能、効率、セキュリティなどの改善に費やすほうがはるかに優れていたでしょう。
また、.so形式のライブラリを提供することで、ユーザーを混乱させるのは非常に簡単ですが、これはユーザーのシステムでは機能しません。（そして、すべてのLinuxシステムで動作させるための超大国がないため、この状況は避けられません。）x86、PowerPC、ARMなどを含む32ビットと64ビットも提供していますか？.soファイルがDebian、Ubuntu、およびRed Hatでのみ機能する場合（ファイルをより多くのディストリビューションに移植する時間がないため）、おそらくSUSEおよびGentooユーザー（およびそれ以上）を混乱させるでしょう。
理想的には、GNU autoconf、automake、およびlibtoolを使用してconfigureおよびmakeスクリプトを作成し、生成されたconfigureおよびMakefile.inファイルとともにライブラリをソースとして配布することをお勧めします。
これがそれらについてのオンライン本です。
./configure; make; make installLinuxではかなり標準的です。
問題の根本は、Linuxが多くの異なるプロセッサで実行されていることです。Windowsのようにx86命令をサポートするプロセッサだけに頼ることはできません（ほとんどのバージョンでは、Itanium（XP以降）とAlpha（NT 4.0）は例外です）。
問題は、Linux 用の共有ライブラリをどのように開発するかということです。このチュートリアルまたはPogram Library Howto をご覧ください。
私はあなたが何を求めているか知っています。Windows の場合、MSFT は慎重にすべての DLL に互換性を持たせているため、通常、DLL は Windows のほぼすべてのバージョンと互換性があります。そのため、「移植可能」と呼ばれます。
残念ながら、Linux ではバリエーションが多すぎて (誰もがお金を稼ぐために「違う」と考えています)、Windows と同じ利点を得ることができません。そのため、さまざまなディストリビューション、ディストリビューション バージョン、 CPUタイプ、...
この問題は (CPU) アーキテクチャが原因であると言う人もいますが、そうではありません。同じアーキテクチャでも、ディストリビューションによって違いがあります。実際にバイナリ パッケージをリリースしようとすると、それがどれほど難しいかがわかります。C ランタイム ライブラリの依存関係を維持することさえ困難です。Linux OS にはあまりにも多くのものが不足しているため、ほとんどすべてのサービスに依存関係の問題があります。
通常、あるディストリビューション (運が良ければ複数のディストリビューション) と互換性のあるバイナリしかビルドできません。そのため、Linux プログラムをバイナリでリリースすると、Ubuntu、Debian、または RH などのディストリビューションにバインドされていない限り、常に失敗します。
.so ファイルを /usr/lib に入れるだけでうまくいくかもしれませんが、ディストリビューションがライブラリを管理するために持っているスキームを台無しにする可能性があります。
Linux 標準ベースを見てみましょう。これは、Linux ディストリビューションの中で共通のプラットフォームに最も近いものです。
http://www.linuxfoundation.org/collaborate/workgroups/lsb
何を達成しようとしていますか？
Tinkertim の答えは的を射ています。gcc の ABIへの変更を理解し、計画することが重要であることを付け加えておきます。最近はかなり安定しており、主要なディストリビューションはすべて gcc 4.3.2 程度であると思います。ただし、数年ごとに、ABI (特に C++ 関連の部分) への何らかの変更が大騒ぎを引き起こしているようです。少なくとも、クロス ディストリビューション バイナリをリリースしたいユーザーや、実際よりも他のディストリビューションからパッケージを取得することに慣れているユーザーにとっては。実行して、それらが機能することを発見します。これらの移行の 1 つが進行している間 (すべてのディストリビューションが独自のペースでアップグレードされます)、理想的には、ユーザーが使用している gcc バージョンの全範囲をサポートする ABI を含むライブラリをリリースする必要があります。