回答:
共有ライブラリは.so（またはWindows .dllまたはOS X .dylib）ファイルです。ライブラリに関連するすべてのコードはこのファイルにあり、実行時にそれを使用するプログラムによって参照されます。共有ライブラリを使用するプログラムは、共有ライブラリで使用するコードのみを参照します。
静的ライブラリは.a（またはWindowsの.lib）ファイルです。ライブラリに関連するすべてのコードはこのファイルにあり、コンパイル時にプログラムに直接リンクされます。静的ライブラリを使用するプログラムは、使用するコードのコピーを静的ライブラリから取得し、プログラムの一部にします。[Windowsには.dllファイルの参照に使用される.libファイルもありますが、最初のファイルと同じように動作します]。
各方法には長所と短所があります。
共有ライブラリは、ライブラリを使用する各プログラムで複製されるコードの量を減らし、バイナリを小さく保ちます。また、共有オブジェクトを機能的に同等のオブジェクトに置き換えることもできますが、それを利用するプログラムを再コンパイルする必要なく、パフォーマンス上の利点が追加される場合があります。ただし、ライブラリ内のすべてのシンボルを使用するものに接続する必要があるため、共有ライブラリには、関数の実行にわずかな追加コストとランタイムロードコストがかかります。さらに、実行時に共有ライブラリをアプリケーションにロードできます。これは、バイナリプラグインシステムを実装するための一般的なメカニズムです。
静的ライブラリーはバイナリーの全体的なサイズを増やしますが、使用されているライブラリーのコピーを持ち歩く必要がないことを意味します。コードはコンパイル時に接続されるため、実行時にロードするための追加のコストはありません。コードは単にそこにあります。
個人的には、共有ライブラリを好みますが、特定のバージョンのC ++標準ライブラリや特定のバージョンのBoost C ++ライブラリなど、満たすのが難しい外部依存関係がバイナリにないようにする必要がある場合は、静的ライブラリを使用します。
簡略化：
静的ライブラリの場合、コードはリンカーによってライブラリから抽出され、アプリケーションをコンパイル/ビルドした時点で最終的な実行可能ファイルをビルドするために使用されます。最終的な実行可能ファイルは、実行時にライブラリに依存しません。
共有ライブラリの場合、コンパイラ/リンカーは、アプリケーションのビルド時にリンク先の名前がライブラリに存在することを確認しますが、コードをアプリケーションに移動しません。実行時には、共有ライブラリが使用可能である必要があります。
Cプログラミング言語自体には、静的ライブラリまたは共有ライブラリの概念はありません。これらは完全に実装機能です。
個人的には、ソフトウェアの配布を簡単にするため、静的ライブラリーを使用することを好みます。しかし、これは過去に多くの（比喩的な）血が流されてきたという意見です。
静的ライブラリはアプリケーションの一部としてコンパイルされますが、共有ライブラリはコンパイルされません。共有ライブラリ、ライブラリなどに依存するアプリケーションを配布する場合。MS Windows上のDLLをインストールする必要があります。
静的ライブラリの利点は、アプリケーションを実行しているユーザーに依存関係が必要ないことです。たとえば、DLLをアップグレードする必要はありません。欠点は、必要なすべてのライブラリーと共に出荷するため、アプリケーションのサイズが大きくなることです。
共有ライブラリは、より小さなアプリケーションにつながるだけでなく、アプリケーションの一部であるライブラリに依存するのではなく、独自の、おそらくより良いバージョンのライブラリを使用する機能をユーザーに提供します
共有ライブラリの最も重要な利点は、ライブラリを使用しているプロセスの数に関係なく、メモリに読み込まれるコードのコピーが1つしかないことです。静的ライブラリの場合、各プロセスは独自のコードのコピーを取得します。これにより、メモリが大幅に浪費される可能性があります。
OTOH、静的ライブラリの利点は、すべてがアプリケーションにバンドルされていることです。したがって、クライアントが適切なライブラリ（およびバージョン）をシステムで使用できるようになることを心配する必要はありません。
.so* nixシステム上のファイルは、共有（動的）ライブラリです。
他のすべての答えに加えて、まだ言及されていないことが、デカップリングです：
私が扱ってきた実際の製品コードについて話させてください：
300以上のプロジェクト（Visual Studioを使用）で構成された非常に大きなソフトウェアは、ほとんどが静的libとしてビルドされ、最終的にすべて1つの巨大な実行可能ファイルにリンクされ、次の問題が発生します。
-リンク時間が非常に長い。リンクに15分以上かかる可能性があります。たとえば、コンパイル時間が数十秒になる場合があります。一部のツールは、コードをインストルメント化する必要があるメモリチェックツールなど、非常に大きな実行可能ファイルを抱えています。あなたは愚か者と見なされていた限界に達するかもしれません。
さらに問題なのは、ソフトウェアの分離です。この現実の例では、すべてのプロジェクトのヘッダーファイルが他のプロジェクトから到達可能です。その結果、1人の開発者が依存関係を追加するのは非常に簡単でした。最後のリンクはシンボルをすべて検出するため、ヘッダーを含めるだけでした。それは恐ろしいサイクリング依存関係と完全な混乱によって終わります。
共有ライブラリでは、開発者がプロジェクトビルドシステムを編集して依存ライブラリを追加する必要があるため、これは少し手間がかかります。共有ライブラリコードは、よりクリーンなコードAPIを提供する傾向があることを確認しました。
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------