ソースから物事をコンパイルすることを学ぶ（Unix / Linux / OSX）
私は可能な限りパッケージ（MacPorts/apt-get）からソフトウェアをインストールしていますが、ソースからパッケージをコンパイルする必要があることがよくあります。 ./configure && make && Sudo make installで通常は十分ですが、機能しない場合もあります。機能しない場合は、行き詰まってしまいます。これはほとんど常に、何らかの方法で他のライブラリの依存関係に関係しています。
私は以下を学びたいと思います：
./configureに渡す引数はどのようにしてわかりますか？- OS X/Linuxで共有ライブラリがどのように機能するか-それらがファイルシステムに存在する場所、
./configure && makeがそれらを見つける方法、リンクされたときに実際に何が起こるか - 共有ライブラリと静的にリンクされたライブラリの実際の違いは何ですか？すべてを静的にリンクするだけで（最近のRAMとディスク容量が安い）、ライブラリバージョンの奇妙な競合を回避できないのはなぜですか？
- インストールしたライブラリとバージョンを確認するにはどうすればよいですか？
- 通常のシステムを壊すことなく、ライブラリの複数のバージョンをインストールするにはどうすればよいですか？
- 私がamパッケージを使用して管理されているシステムにソースからのものをインストールする場合、そうするための最もクリーンな方法は何ですか？
- ソースから手間をかけてなんとかコンパイルできたとしたら、他の人が同じフープを飛び越える必要がないように、どうしたらそれをパッケージ化できるでしょうか？特にOS Xで...
- この機能を使いこなすために習得する必要があるコマンドラインツールは何ですか？ otool、pkg-configなどのようなもの.
私はここにかなりの時間と労力を費やすつもりです-上記の質問に直接回答する必要はありません。本、チュートリアル、FAQに関する推奨事項を知りたいと思います。実際に何が起こっているのかを理解し、自分で問題を解決する必要がある知識。
私はすべてに直接回答したことをお詫び申し上げますが、役に立つチュートリアルやFAQなどは知りません。基本的に、デスクトップアプリ（配布に役立つ）を作成してから8年間、欲求不満とグーグルが続いています。
1。 ./configureに渡す引数を見つけるにはどうすればよいですか
本当に練習してください。 Autotoolsは一貫しているので十分簡単です。しかし、cmake、またはカスタムビルドスクリプトを使用することはたくさんあります。一般に、構成に何も渡す必要はありません。システムがfoo-toolを構築できるかどうかを判断する必要があります。
構成とGNUツールはすべて依存関係の/、/ usrおよび/ usr/localを調べます。他の場所に何かをインストールすると（依存関係がMacPortsまたはFinkによってインストールされた場合に問題が発生します）、シェルの環境を構成または変更するには、フラグを渡してGNUツールがこれらの依存関係を検出できるようにする必要があります。
2。 OS X/Linuxで共有ライブラリがどのように機能するか-それらがファイルシステムに存在する場所、。/ configure && makeがそれらを見つける方法、それらがリンクされたときに実際に何が起こるか
Linuxでは、動的リンカーが検出できるパスにインストールする必要があります。これは、LD_LIBRARY_PATH環境変数と/etc/ld.confの内容。 Macでは、ほとんどのオープンソースソフトウェアで同じです（Xcodeプロジェクトでない限り）。 env変数がDYLD_LIBRARY_PATH代わりに。
リンカがライブラリを検索するデフォルトのパスがあります。/lib：/ usr/lib：/ usr/local/lib
これを補足するには、CPATH変数、CFLAGS、または他の任意の数の環境変数を使用します（便利なように複雑です）。 CFLAGSを次のように提案します。
cFLAGS = "$ CFLAGS -L/new/path"をエクスポートします
-Lパラメーターはリンクパスに追加されます。
最新のものはpkg-configツールを使用します。インストールする最新のものは、ライブラリとその場所、およびリンク方法を説明する.pcファイルもインストールします。これにより、生活が楽になります。ただし、OS X 10.5には付属していないため、これもインストールする必要があります。また、多くの基本的な開発者はそれをサポートしていません。
リンクの動作は、「実行時にこの関数を解決する」だけで、実際には大きな文字列テーブルです。
3。共有ライブラリと静的にリンクされたライブラリの実際の違いは何ですか？すべてを静的にリンクするだけで（最近のRAMとディスク容量が安い）、ライブラリバージョンの奇妙な競合を回避できないのはなぜですか？
静的ライブラリファイルにリンクすると、コードはアプリケーションの一部になります。これは、そのライブラリ用の巨大な.cファイルが1つあり、それをアプリケーションにコンパイルした場合のようになります。
動的ライブラリには同じコードがありますが、アプリを実行すると、実行時にコードがアプリに読み込まれます（簡単な説明）。
すべてに静的にリンクできますが、残念ながら、どのビルドシステムでもこれを簡単に行うことはできません。ビルドシステムファイルを手動で編集する必要があります（Makefile.am、CMakeLists.txtなど）。ただし、異なるバージョンのライブラリを必要とするものを定期的にインストールし、依存関係を並行してインストールすることが難しい場合は、これはおそらく学ぶ価値があります。
コツは、リンク行を-lfooから-l/path/to/static/foo.aに変更することです。
おそらく見つけて置き換えることができます。その後、ldd fooまたはotool -L fooを使用して、ツールが.soまたはdylibにリンクしていないことを確認します。
別の問題は、すべてのライブラリが静的ライブラリにコンパイルされるわけではないことです。多くの人がします。しかし、MacPortsやDebianはそれを出荷しないことに決めたかもしれません。
4。インストールしたライブラリとバージョンを確認するにはどうすればよいですか？
これらのライブラリ用のpkg-configファイルがある場合は簡単です。
pkg-config --list-all
そうしないと、簡単にできないことがよくあります。 dylibには、ライブラリのバージョンと同じsoname（つまり、foo.0.1.dylib、sonameは0.1）がある場合があります。ただし、これは必須ではありません。 sonameはバイナリ演算機能であり、ライブラリ内の関数の形式を変更する場合は、sonameの大部分をバンプする必要があります。だからあなたは例えば得ることができます。 2.0ライブラリのバージョン14.0.5 soname。これは一般的ではありませんが。
私はこの種のものに不満を抱き、Macでこれに対するソリューションを開発しました。次にそれについて話します。
5。通常のシステムを壊すことなく、ライブラリの複数のバージョンをインストールするにはどうすればよいですか？
これに対する私の解決策はここにあります： http://github.com/mxcl/homebrew/
私はソースからのインストールが好きで、それを簡単にするツールを求めていましたが、いくつかのパッケージ管理が必要でした。だから私は自作で私はビルドします。ソースからwgetしますが、必ず特別なプレフィックスにインストールしてください。
/usr/local/Cellar/wget/1.1.4
次に、homebrewツールを使用してすべてを/ usr/localにシンボリックリンクしているため、/ usr/local/bin/wgetと/usr/local/lib/libwget.dylibがまだあります。
後で別のバージョンのwgetが必要な場合は、並行してインストールし、/ usr/localツリーにリンクされているバージョンを変更するだけです。
6。パッケージを使用して管理されているシステムにソースからのものをインストールする場合、最もクリーンな方法は何ですか？
Homebrewの方法が最もクリーンだと思うので、それを使用するか、同等のものを使用します。/usr/local/pkgs/name/versionにインストールし、残りをシンボリックリンクまたはハードリンクします。
/ usr/localを使用してください。存在するすべてのビルドツールは、依存関係とヘッダーを検索します。あなたの人生はずっと簡単になります。
7。ソースから手間をかけてなんとかコンパイルできたとしたら、他の人が同じフープを飛び越える必要がないように、どうしたらそれをパッケージ化できるでしょうか？特にOS Xで...
依存関係がない場合は、ビルドディレクトリをtarにして、「make install」を実行できる他の人に渡してください。ただし、これを確実に行うことができるのは、OS Xのまったく同じバージョンに対してのみです。Linuxでは、同じカーネルバージョンとlibcマイナーバージョンを備えた同様のLinux（Ubuntuなど）でおそらく動作します。
Unixでバイナリを配布するのが簡単ではない理由は、バイナリ互換性のためです。 GNU人、そして他の誰もがバイナリインターフェイスを頻繁に変更します。
基本的にバイナリを配布しないでください。物事はおそらく非常に奇妙な方法で壊れます。
Macでは、最善のオプションはmacportsパッケージを作成することです。誰もがMacportsを使用しています。 Linuxには非常に多くの異なるビルドシステムと組み合わせがあるため、奇妙な構成でxツールのビルドに成功したことについてブログエントリを書くよりも良いアドバイスはないと思います。
パッケージの説明（macportsまたはhomebrew用）を作成すると、誰でもそのパッケージをインストールでき、依存関係の問題も解決されます。ただし、これは簡単ではないことが多く、MacportsのレシピをメインのMacportsツリーに含めることも簡単ではありません。また、macportsは新しいインストールタイプをサポートしていません。すべてのパッケージに1つの選択肢を提供します。
Homebrewの私の将来の目標の1つは、Webサイトのリンクをクリックできるようにすることです（たとえば、homebrew：// blahとすると、Rubyスクリプトがダウンロードされ、そのパッケージのdepsがインストールされます）アプリをビルドしますが、まだ完了していませんが、選択したデザインを考えると、それほどトリッキーではありません。
8。この機能を使いこなすために習得する必要があるコマンドラインツールは何ですか？ otool、pkg-configなどのようなもの
otoolが本当に役立つのはその後だけです。ビルドされたバイナリのリンク先を示します。ビルドする必要のあるツールの依存関係を把握する場合、それは役に立ちません。依存関係を使用する前にインストールしておくので、pkg-configにも同じことが言えます。
私のツールチェーンは、READMEとINSTALLファイルを読んで、configure --helpを実行します。ビルドの出力を監視して、正常であることを確認します。ビルドエラーを解析します。将来的には、 serverfault :)
これは大きなトピックなので、Linuxの共有ライブラリ（LinuxではELF、OS XではMach-O）から始めましょう。UlrichDrepperは、DSOの作成についての優れた はじめに （動的共有オブジェクト）共有のいくつかの履歴をカバーしていますLinuxのライブラリは、なぜ重要なのかなど、ここで入手できます
Ulrichはまた、 静的リンクが有害であると見なされる理由についても説明しています ここでの重要なポイントの1つはセキュリティ更新です。静的に広範囲にリンクされている共通ライブラリ（zlibなど）のバッファオーバーフローは、ディストリビューションに大きなオーバーヘッドを引き起こす可能性があります-これはzlib 1.1.3で発生しました（ Red Hat advisory ）
[〜＃〜] elf [〜＃〜]
リンカーld.soのマニュアルページ
man ld.so
実行時の動的リンクに関連する基本的なパスとファイルについて説明します。最近のLinuxシステムでは、/ etc/ld.so.conf.d /を介して追加された追加のパスが通常/etc/ld.so.confに含まれるグロブを介して追加されます。
Ld.so設定を介して動的に利用できるものを確認したい場合は、実行できます
ldconfig -v -N -X
DSOのhowtoを読むことで、これらの原則がOS XのMach-Oにどのように適用されるかを理解するために、適切な基本レベルの知識が得られるはずです。
マッハ-O
OS Xでは、バイナリ形式はMach-Oです。リンカのローカルシステムドキュメントは
man dyld
Mach形式のドキュメント はAppleから入手できます
UNIXビルドツール
一般的なconfigure、make、make installプロセスは、一般にGNU autotoolsによって提供されます。これには、 オンラインブック が構成の履歴の一部をカバーしています/ build splitとGNUツールチェーン。 Autoconf は、テストを使用してターゲットビルドシステムでの機能の可用性を判断し、 M4マクロ言語を使用して これを駆動します。 Automake は基本的にMakefileのテンプレートメソッドです。テンプレートは一般的にMakefile.amと呼ばれ、autoconf（構成スクリプト）の出力がMakefileに変換されるMakefile.inを出力します。
GNU hello プログラムは、GNUツールチェーンを理解するための良い例として機能し、マニュアルにはautotoolsのドキュメントが含まれています。
サイモン！お気持ち察します; Linuxの学習のこの部分にも苦労しました。私自身の経験に基づいて、私があなたが取り組むいくつかの項目についてのチュートリアルを書きました（主に私自身の参照として！）： http://easyaspy.blogspot.com/2008/12/buildinginstalling-application- from.html 。 Pythonアプリケーションのビルド/インストールがいかに簡単であるかについての私のメモに感謝します。:)
これがお役に立てば幸いです！そして幸せなコンパイル。
ティム・ジョーンズ
Ubuntu Linuxでソースからアプリケーションをビルド/インストールする
Ubuntuリポジトリには素晴らしいアプリケーションがぎっしり詰まっていますが、リポジトリにない（またはDebianパッケージがない）「必須」ツールに出くわすこともあれば、リポジトリよりも新しいバージョン。職業はなんですか？まあ、あなたはソースからアプリケーションを構築する必要があります！心配する必要はありません。実際にはそれほど複雑ではありません。ここでは、素人ランクからの私の経験に基づくいくつかのヒントがあります！ （この例ではUbuntuを使用していますが、一般的な概念は、FedoraなどのほとんどのUnix/Linuxディストリビューション、さらにはWindows上のCygwinプラットフォームにも適用できます。）
ほとんどのアプリケーションをソースからビルド（コンパイル）する基本的なプロセスは、次のシーケンスに従います：構成->コンパイル->インストール。これらのことを行う典型的なUnix/Linuxコマンドは次のとおりです：config-> make-> make install。場合によっては、これらすべてを1つのコマンドに組み合わせることができることを示すWebページを見つけることもあります。
$ config && make && make install
もちろん、このコマンドは、これらのステップのいずれにも問題がないことを前提としています。ここからがおもしろいところです。
はじめに
以前にシステムのソースからアプリケーションをコンパイルしたことがない場合は、gccコンパイラスイート、いくつかの一般的なヘッダーファイルなどの一般的な開発ツールでセットアップする必要があります（これはインストールしているプログラムで使用されている他の誰かによってすでに記述されているコード）、およびmakeツール。幸い、Ubuntuには、これをインストールするbuild-essentialというメタパッケージがあります。これをインストールするには（または、すでにインストールされていることを確認してください！）、ターミナルで次のコマンドを実行します。
$ Sudo apt-get install build-essential
基本的なセットアップが完了したので、アプリケーションのソースファイルをダウンロードし、「ホーム」ディレクトリなど、読み取り/書き込み権限を持つディレクトリに保存します。通常、これらはファイル拡張子が.tar.gzまたは.tar.bz2のアーカイブファイルにあります。 .tarは、単にそれが「テープアーカイブ」であることを意味します。これは、相対的なディレクトリ構造を保持するファイルのグループです。 .gzは、一般的なUnix/Linux圧縮形式であるgzip（GNU Zip）を表します。同様に、.bz2はbzip2を表します。これは、gzipよりも高い圧縮率（小さい圧縮ファイルサイズ）を提供する新しい圧縮形式です。
ソースファイルをダウンロードしたら、ターミナルウィンドウ（Ubuntuメニューの[システムターミナル]）を開き、ファイルを保存したディレクトリに移動します。 （この例では~/downloadを使用します。ここで、「〜」は「ホーム」ディレクトリへのショートカットです。）tarコマンドを使用して、ダウンロードしたアーカイブファイルからファイルを抽出します。
ファイルがgzipアーカイブ（例：.tar.gzで終わる）の場合は、次のコマンドを使用します。
$ tar -zxvf filename.tar.gz
ファイルがbzip2アーカイブ（例：.tar.bz2で終わる）の場合は、次のコマンドを使用します。
$ tar -jxvf filename.tar.gz
ヒント：アーカイブを抽出するためのすべてのコマンドラインスイッチを覚える必要がない場合は、dtrx（私のお気に入り！）またはdeco（より人気のある）のいずれか（または両方）のユーティリティを入手することをお勧めします。これらのユーティリティのいずれかを使用すると、ユーティリティの名前（dtrxまたはdeco）とファイル名を入力するだけで、残りのすべてが実行されます。これらはどちらも、実行される可能性が高いほとんどすべてのアーカイブ形式を処理する方法を「認識」しており、優れたエラー処理を備えています。
ソースからビルドする場合、発生する可能性が高い一般的なエラーには2つのタイプがあります。
- 構成に固有のメイクファイルを作成する構成スクリプト（通常はconfigまたはconfigure）を実行すると、構成エラーが発生します。
- （makefileの生成後に）makeコマンドを実行するとコンパイラエラーが発生し、コンパイラは必要なコードを見つけることができません。
これらのそれぞれを見て、それらを解決する方法について説明します。
構成と構成エラー
ターミナルでソースコードアーカイブファイルを抽出したら、抽出したファイルを含むディレクトリに移動する必要があります。通常、このディレクトリ名はファイルの名前と同じになります（.tar.gzまたは.tar.bz2拡張子なし）。ただし、ディレクトリ名がバージョン情報のないアプリケーションの名前である場合もあります。
ソースディレクトリでREADMEファイルやINSTALLファイル（または類似した名前のファイル）を探します。これらのファイルには通常、依存関係に関する情報を含め、アプリケーションのビルド/コンパイル方法とインストール方法に関する有用な情報が含まれています。 「依存関係」は、正常にコンパイルするために必要な他のコンポーネントまたはライブラリの単なる仮名です。
READMEおよび/またはINSTALLファイルを読んだ後（および、アプリケーションに関連するオンラインドキュメントを参照してください）、実行可能ファイルを探します（ "x"権限がオンに設定されています）ファイル）configまたはconfigureという名前のファイル。場合によっては、ファイルに.shなどの拡張子が付いていることがあります（例：config.sh）。これは通常、他のユーティリティを実行して、コンパイル用の「正常な」環境であることを確認するシェルスクリプトです。つまり、必要なものがすべてインストールされていることを確認します。
ヒント：これが構成ファイルの代わりにPythonベースのアプリケーションである場合は、
setup.pyという名前のファイルを見つける必要があります。 Pythonアプリケーションは通常、インストールが非常に簡単です。このアプリケーションをインストールするには、ルートとして（たとえば、Ubuntuで次のコマンドの前にSudoを配置します）、次のコマンドを実行します。$ python setup.py installそれだけで十分です。このチュートリアルの残りの部分をスキップして、アプリケーションの使用と楽しみに直接進むことができます。
ターミナルで設定スクリプトを実行します。通常は、通常のユーザーアカウントで構成スクリプトを実行できます（そうする必要があります！）。
$ ./config
スクリプトはいくつかのメッセージを表示して、それが何をしているのかをあなたに知らせます。多くの場合、スクリプトは、成功したか失敗したかを示し、失敗した場合は、失敗の原因に関する情報を提供します。エラーメッセージが表示されない場合は、通常、すべてが正常に行われたと考えられます。
構成スクリプトのようなスクリプトが見つからない場合、それは通常、アプリケーションが非常に単純なものであり、プラットフォームに依存しないことを意味します。これは、提供されているMakefileがどのシステムでも機能するため、以下のビルド/コンパイル手順にスキップできることを意味します。
例
このチュートリアルでは、アプリケーションの構築時に発生する可能性のあるエラーの種類の例として、NewsbeuterというテキストベースのRSSリーダーを使用します。 Newsbeuterの場合、構成スクリプトの名前はconfig.shです。私のシステムでconfig.shを実行すると、次のエラーが発生します。
tester@sitlabcpu22:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found
You need package sqlite3 in order to compile this program.
Please make sure it is installed.
調査の結果、実際にはsqlite3アプリケーションがインストールされていることがわかりました。ただし、ソースからビルドしようとしているため、これはconfig.shが実際に探しているのはsqlite3の開発ライブラリ（ヘッダー）であるというヒントです。 Ubuntuでは、ほとんどのパッケージに-devで終わる開発用の対応パッケージが関連付けられています。 （Fedoraなどの他のプラットフォームでは、多くの場合、開発パッケージに-develのパッケージサフィックスを使用します。）
sqlite3開発パッケージに適切なパッケージを見つけるには、Ubuntuのapt-cacheユーティリティを使用できます（同様に、Fedoraのyumユーティリティ）。
tester@sitlabcpu22:~/download/newsbeuter-1.3$ Sudo apt-cache search sqlite
このコマンドは結果の非常に大きなリストを返すため、適切なパッケージを判別するために少しの調査作業を行う必要があります。この場合、適切なパッケージはlibsqlite3-devになります。同じパッケージ名に-devを加えたものではなく、探しているパッケージにlibプレフィックスが付いている場合があることに注意してください。これは、多くの場合、さまざまなアプリケーションで使用できる共有ライブラリを探しているだけだからです。 libsqlite3-devをインストールするには、ターミナルで一般的なapt-get installコマンドを実行します。
tester@sitlabcpu22:~/download/newsbeuter-1.3$ Sudo apt-get install libsqlite3-dev
ここで、config.shを再度実行して、この依存関係の問題が解決し、依存関係の問題が発生していないことを確認する必要があります。 （ここでは表示しませんが、Newsbeuterの場合、libcurl4-openssl-devパッケージもインストールする必要がありました。）また、開発パッケージ（libsqlite3-devなど）をインストールし、関連するアプリケーションパッケージ（たとえば、sqlite3）はまだインストールされていません。ほとんどのシステムでは、関連するアプリケーションパッケージが同時に自動的にインストールされます。
構成が正常に実行されると、結果として1つ以上のmakeファイルが作成されます。これらのファイルは通常Makefileという名前です（Unix/Linuxではファイル名の大文字と小文字が区別されることに注意してください）。ビルドパッケージにsrcなどのサブディレクトリが含まれている場合、これらの各サブディレクトリにはMakefileも含まれます。
ビルドおよびコンパイルエラー
これで、実際にアプリケーションをコンパイルする準備ができました。これはしばしば建物と呼ばれ、名前は何かを構築する実際のプロセスから借用されました。アプリケーションのさまざまな「部分」（通常は複数のソースコードファイル）を組み合わせて、アプリケーション全体を形成します。 makeユーティリティはビルドプロセスを管理し、コンパイラやリンカーなどの他のアプリケーションを呼び出して、実際に作業を行います。ほとんどの場合、構成を実行したディレクトリから（通常のユーザーアカウントで）makeを実行するだけです。 （Qtライブラリで作成されたアプリケーションをコンパイルする場合など、いくつかのケースでは、代わりにqmakeなどの別の「ラッパー」アプリケーションを実行する必要があります。ここでも、常にREADMEまたはINSTALLを確認してください詳細はドキュメント。）
上記の構成スクリプトと同様に、ターミナルでmake（または同様のユーティリティ）を実行すると、実行中のメッセージと警告およびエラーが表示されます。警告は主にアプリケーションの開発者向けであり、違反されているいくつかの標準的なプラクティスがあることを警告しているため、通常は警告を無視できます。通常、これらの警告はアプリケーション機能に影響を与えません。一方、コンパイラエラーは処理する必要があります。 Newsbeuterを使用してmakeを実行したところ、しばらく問題はありませんでしたが、エラーが発生しました。
tester@sitlabcpu22:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1
Makeプロセスは、最初のエラーが発生するとすぐに停止します。コンパイラー・エラーの処理は、扱いにくいビジネスになることがあります。あなたは問題についてのいくつかの手がかりのためにエラーを見なければなりません。通常、問題は、通常.hまたは.hppの拡張子を持つ一部のヘッダーファイルが見つからないことです。上記のエラーの場合、問題はstfl.hヘッダーファイルが見つからないことである（またはそうであるはずです！）ことは明らかです。この例が示すように、エラーメッセージの最初の行を確認して、問題の根本的な原因を突き止める必要があります。
Newsbeuterのドキュメント（開始する前に行っておくべきでしたが、チュートリアルのこの部分はあまり意味がありません）を調べたところ、STFLと呼ばれるサードパーティのライブラリが必要であることがわかりました。では、この場合はどうしますか？ええと、基本的には、必要なライブラリに対してこのまったく同じプロセスを繰り返します。ライブラリを取得し、そのライブラリに対してconfigure-build-installプロセスを実行してから、目的のアプリケーションのビルドを再開します。たとえば、STFLの場合、正常にビルドするにはlibncursesw5-devパッケージをインストールする必要がありました。 （通常、別の必要なアプリケーションをインストールした後、元のアプリケーションで構成手順をやり直す必要はありませんが、問題が発生することはありません。）
STFLツールキットを正常にインストールした後、Newsbeuterのmakeプロセスが正常に実行されました。通常、makeプロセスは、（エラーが発生した時点で）中断したところから再開します。したがって、すでに正常にコンパイルされたファイルは再コンパイルされません。すべてを再コンパイルする場合は、make clean allを実行して、コンパイルされたオブジェクトを削除してから、makeを再度実行します。
インストール中
ビルドプロセスが正常に完了すると、アプリケーションをインストールする準備が整います。ほとんどの場合、アプリケーションをファイルシステムの共通領域（たとえば、/usr/binまたは/usr/share/binなど）にインストールするには、インストールをrootとして実行する必要があります。インストールは、プロセス全体で本当に最も簡単なステップです。インストールするには、ターミナル実行で：
$ make install
このプロセスの出力でエラーを確認します。すべてが成功した場合は、ターミナルでコマンド名を実行でき、起動します。 （GUIアプリケーションの場合は、コマンドラインの最後に＆を追加します。そうしないと、アプリケーションの実行が完了するまでターミナルセッションを使用できません。）
ソースからアプリケーションをビルドすると、通常、UbuntuのGUIメニューにアイコンやショートカットが追加されません。これは手動で追加する必要があります。
そして、それは基本的に、Ubuntuのソースからアプリケーションをビルドしてインストールするための、潜在的に反復的ではありますが、プロセスです。これをほんの数回行った後、それはあなたにとって第二の性質になります！
さて、。/ configure --helpは、GNU autotoolsが生成した構成ファイルについて、多くの情報を提供します。そのほとんどは、機能を有効にするための--with /-withoutです（これらのライブラリの場所を示す「共有」などの追加のパラメータを使用する場合があります）。
他の重要なものは--prefix（デフォルトは/ usr/local /がデフォルト）で、どこにインストールするかを指定します（パッケージをビルドしている場合は、通常これを--prefix =/usrまたは多分--prefixとして使用します） =/opt/YourPackage）。
Linuxでは、/ lib、/ usr/libおよび/ usr/local/libは通常、gccで検索され、ldconfigのデフォルト設定に含まれています。正当な理由がない限り、ここにライブラリが必要です。ただし、/ etc/ld.so.confは追加のエントリをリストする場合があります。
"gcc -l"を実行してエラーが発生するかどうかを確認するだけで、構成と検索ができます。 CFLAGSパラメータに「-L」を追加して、検索するパスを追加できます。
複数のバージョンをインストールすることができ、古いバージョンに対してリンクされたソフトウェアは引き続きリンクされます（lddを実行してLinux上のバインディングを確認します）が、新しいコンパイルは通常、システム上の動的ライブラリの最新バージョンをターゲットにします。
ほとんどのソフトウェアは、特にlibtoolを使用する場合、動的libを想定しているため、重要なアプリが静的に正しくビルドされない場合があります。
ls -lは、インストールされているライブラリを見つけるための最善の方法です。
そして、それは私が情報が不足しているところです。パッケージでうまく遊ぶ方法：わからない。可能な場合は、問題を回避するために物事をパッケージにまとめます。
あなたの質問に少し答えるために、先日インストールしたライブラリとバージョンを確認する良い方法を見つけました（これはLinux Debianにあるため、他のバージョンでも動作するはずです）。
dpkg --list
あなたはこのようないくつかの出力を持つ本当に長いリストを取得する必要があります
ii libssl0.9.8 0.9.8c-4etch5 SSL shared libraries
ii libssp0 4.1.1-21 GCC stack smashing protection library
ii libstdc++5 3.3.6-15 The GNU Standard C++ Library v3
ii libstdc++5-3.3 3.3.6-15 The GNU Standard C++ Library v3 (development
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
「どの引数を./configureに渡すかを知るにはどうすればよいですか？」
通常：./configure --helpはそこに何が欲しいかを教えてくれます。
「インストールしたライブラリとバージョンを確認するにはどうすればよいですか？」
それはシステムに依存します。 1つの方法は、find /|grep libname|lessを実行することです。通常、ライブラリファイルにはファイル名にバージョンが含まれているためです。
「通常のシステムを壊すことなく、どのようにしてライブラリの複数のバージョンをインストールできますか？」
繰り返しますが、システムとライブラリによって異なります。 Sudo make altinstallがバージョン管理された名前を作成します。ただし、ライブラリファイルは通常、自分自身をバージョン管理します。ただし、覚えておいてください。バージョンはしばしば「正規化された」名前へのシンボリックリンクを作成するため、これは事態を壊す可能性があります。
「別の方法でパッケージを使用して管理されているシステムにソースからのものをインストールする場合、最もクリーンな方法は何ですか？」
./configureで--prefixパラメータを使用し、それらを/optのどこかに配置することをお勧めします。
免責事項：私は決して専門家ではありませんが、5年間以上Linuxを使用していますcmd行から（slackware、CentOS、redhat、ubuntu、その他、およびOS X）。
サイモン、
1.）./configure --helpは十分な情報を提供します。ぜひチェックしてみてください。一般に、適切な場合に静的/動的にリンクされたライブラリをコンパイルするためのオプションがあります。
2.）ライブラリは動的リンカーパスにあります。これは通常/etc/ld.so.confで設定されます。リンカは、最初に見つかったものと一致するPATH環境変数と同様に、適切なライブラリを検索します。
3.）ライブラリのバージョンが変更されたときにすべてを再コンパイルする必要があるため、一般に問題が発生します。検索を行うと、静的リンクが悪い考えである理由がたくさん見つかります。ここまで詳しく説明することができないので、私はそれを長い間行っていません。
4.）これは少し難しいです。ライブラリパスを確認して、確実に確認する必要があります。通常、ライブラリには、インストールされているバージョンへのシンボリックリンクがあります。
例えばlibssh2.so.1-> libssh2.so.1.0.0
一般的に、人々は自分たちがインストールしたライブラリとプログラムを、独自のdebianパッケージをローリングするか、他の何らかの手法を使って管理しています。インストールしたソフトウェアはstow（ http://www.gnu.org/software/stow/ ）を使用して管理します。これは非常にシンプルで、シンボリックリンクを使用してライブラリをインストールします。 deb/rpmパッケージをビルド/インストール/テストする必要がないので、私はそれが簡単だと思います。
5.）ライブラリの複数のバージョンをライブラリディレクトリに正常にインストールできます。実行可能ファイルにリンクされたライブラリは、リンクされたバージョンにリンクされたままになります。実行可能ファイルに対してlddを実行すると、実行可能ファイルがリンクされているライブラリがわかります。
6.）前に述べたように、独自のdebianパッケージをロールするか、stowを使用することがおそらく最もクリーンなソリューションです。
7.）Mac OSXについては実際には話せませんが、Linuxの場合はディストリビューションのパッケージシステムが最良の方法です。
8.）おそらく、lddを使用して、何かがリンクされているバージョンや、実行可能ファイルにリンクされているライブラリが見つからないことを見つけることで、多くのフラストレーションが解決されます。 pkg-configは非常に役立ちますが、それを使用するソフトウェアに対してのみです。最近は人気がありますが、デフォルトのautotoolsビルドシステムの一部ではありません。
質問のリストには明示されていませんが、序文で次のように述べています。
./configure && make && Sudo make installで通常は十分ですが、機能しない場合もあります。機能しない場合は、行き詰まってしまいます。
DebianまたはUbuntuでスタックしているときは、auto-aptを使用します。これにより、構成できないファイルを含むパッケージが自動的にインストールされます。
見る：
- http://www.debian.org/doc/manuals/apt-howto/ch-search.en.html#s-auto-apt
- https://help.ubuntu.com/community/AutoApt
便利な別のツールとして、CheckInstallがあります。これは、インストールされたパッケージのリストにmake installでインストールされたアプリケーションを追加します。 https://help.ubuntu.com/community/CheckInstall
スタティックライブラリは良い考えではありません。たとえば、セキュリティの問題を修正するためにライブラリをアップグレードする必要がある場合は、そのライブラリに依存するすべてのものを再コンパイルする必要があります。
「make install」がシステムを乱雑にする可能性があるのは嫌いですが、他の人が言ったように、通常、--prefixを使用して他の場所にインストールする代わりに、/ usr/localにインストールするほうがはるかに簡単です。そのため、私は/ usr/localを通常の（特権のない）ユーザーに割り当てました。このようにして、「make install」が重要なシステムファイルを混乱させないことがほぼ保証されています。 （これは明らかにマルチユーザーシステムでは機能しません。ただし、仮想サーバーには最適です。）
OS Xの場合：
- ./configureに渡す引数を見つけるにはどうすればよいですか？
./configure --help
- 共有ライブラリと静的にリンクされたライブラリの実際の違いは何ですか？すべてを静的にリンクするだけで（最近のRAMとディスク容量が安い）、ライブラリバージョンの奇妙な競合を回避できないのはなぜですか？
共有ライブラリを使用すると、ライブラリを利用するすべてのものを再コンパイルせずにライブラリをアップグレードできます。
- OS X/Linuxで共有ライブラリがどのように機能するか-それらがファイルシステムに存在する場所、。/ configure && makeがそれらを見つける方法、リンクされたときに実際に何が起こるか
システムライブラリは/ usr/libにあります。
自分でコンパイルしたライブラリは、/ usr/local/libにあります（/ usr/localが./configureのデフォルトの--prefixフラグです）。
環境変数DYLD_FALLBACK_LIBRARY_PATHおよびLD_LIBRARY_PATHを使用すると、検索するフォルダーを指定できるため、/ usr/local/libがリストの先頭にあるはずです。
- 通常のシステムを壊すことなく、ライブラリの複数のバージョンをインストールするにはどうすればよいですか？
すべてを/ usr/localにインストールします-上記の環境変数を使用すると、/ usr/local/libのバージョンが環境の/ usr/libのバージョンよりも優先されます。
- パッケージを使用して管理されているシステムにソースからのものをインストールする場合、最もクリーンな方法は何ですか？
/ usr/localにインストールします。 Ubuntuでは、最初にcheckinstallを使用してdebパッケージを作成します。
- ソースから手間をかけてなんとかコンパイルできたとしたら、他の人が同じフープを飛び越える必要がないように、どうしたらそれをパッケージ化できるでしょうか？特にOS Xで...
ブログの投稿でコンパイル手順を文書化すると思います。