解決策 1:
すべてに直接回答して申し訳ありませんが、役に立つチュートリアル、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 プロジェクトでない限り)。環境変数が DYLD_LIBRARY_PATH であることを除いて
リンカーがライブラリを検索するデフォルトのパスがあります。 /lib:/usr/lib:/usr/local/lib です
CPATH 変数、CFLAGS、またはその他の環境変数を実際に使用することで、これを補うことができます (便利なほど複雑です)。 CFLAGS は次のように提案します:
export CFLAGS="$CFLAGS -L/new/path"
-L パラメータは、リンク パスに追加します。
最新のものは pkg-config ツールを使用します。インストールする最新のものは、ライブラリとその場所、およびライブラリへのリンク方法を説明する .pc ファイルもインストールします。これにより、生活が楽になります。ただし、OS X 10.5 には付属していないため、これもインストールする必要があります。また、多くの基本的な deps はそれをサポートしていません。
リンクの行為は「実行時にこの関数を解決する」だけで、実際には大きな文字列テーブルです.
<強い>3.共有ライブラリと静的にリンクされたライブラリの実際の違いは何ですか?すべてを静的にリンクするだけで (最近は RAM とディスク容量が安価です)、奇妙なライブラリ バージョンの競合を回避できないのはなぜですか?
静的ライブラリ ファイルにリンクすると、コードはアプリケーションの一部になります。そのライブラリ用の 1 つの巨大な .c ファイルがあり、それをアプリケーションにコンパイルしたようなものです。
動的ライブラリには同じコードがありますが、アプリを実行すると、実行時にコードがアプリに読み込まれます (簡単な説明)。
すべてに静的にリンクできますが、残念ながらこれを簡単に行えるビルドシステムはほとんどありません。ビルド システム ファイルを手動で編集する必要があります (例:Makefile.am または CMakeLists.txt)。ただし、異なるバージョンのライブラリを必要とするものを定期的にインストールし、依存関係を並行してインストールするのが難しいと感じている場合は、おそらくこれを学ぶ価値があります。
秘訣は、リンク行を -lfoo から -l/path/to/static/foo.a に変更することです
おそらく見つけて置き換えることができます。その後、ldd foo または otool -L foo を使用して、ツールが .so または dylib にリンクしていないことを確認します
もう 1 つの問題は、すべてのライブラリが静的ライブラリにコンパイルされるわけではないことです。多くの人がそうします。しかしその後、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/
私はソースからインストールするのが好きで、簡単にインストールできるツールが欲しかったのですが、パッケージ管理が少しありました。だからHomebrewで私はビルドします。ソースから自分自身を取得しますが、必ず特別なプレフィックスにインストールしてください:
/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 で質問してください :)
解決策 2:
これは大きなトピックなので、Linux の共有ライブラリ (Linux の ELF と OS X の Mach-O) から始めましょう。Ulrich Drepper は、Linux で利用可能な共有ライブラリの歴史をカバーする DSO (動的共有オブジェクト) を書くための良い入門書を持っています。重要な理由も含めて
Ulrich は、静的リンクが有害であると見なされる理由についても説明しています。重要なポイントの 1 つは、セキュリティ アップデートです。静的に広範囲にリンクされている共通ライブラリ (zlib など) でのバッファ オーバーフローは、ディストリビューションに大きなオーバーヘッドを引き起こす可能性があります - これは zlib 1.1.3 で発生しました (Red Hat アドバイザリ)
エルフ
リンカー ld.so マニュアル ページ
man ld.so
ランタイム動的リンクに関連する基本的なパスとファイルについて説明します。最新の Linux システムでは、追加のパスが /etc/ld.so.conf.d/ 経由で追加され、通常は /etc/ld.so.conf のグロブ インクルード経由で追加されます。
ld.so 構成を介して動的に利用できるものを確認したい場合は、実行できます
ldconfig -v -N -X
DSO のハウツーを読むと、OS X 上の Mach-O にこれらの原則がどのように適用されるかを理解するために、十分な基本レベルの知識が得られます。
マッハ
OS X では、バイナリ形式は Mach-O です。リンカーのローカル システム ドキュメントは
です。man dyld
Mach 形式のドキュメントは Apple から入手できます
UNIX ビルド ツール
共通の configure 、 make 、 make install プロセスは一般に GNU autotools によって提供されます。このオンライン ブックには、configure/build の分割と GNU ツールチェーンの歴史の一部が記載されています。 Autoconf は、テストを使用してターゲット ビルド システムで機能が利用可能かどうかを判断します。これを駆動するために M4 マクロ言語を使用します。 Automake は基本的に Makefile のテンプレート化方法です。テンプレートは一般に Makefile.am と呼ばれ、autoconf (configure スクリプト) の出力が Makefile に変換される Makefile.in を出力します。
GNU hello プログラムは、GNU ツールチェーンを理解するための良い例として機能し、マニュアルには autotools のドキュメントが含まれています。
解決策 3:
シモン！お気持ち察します; Linux の学習のこの部分にも苦労しました。私自身の経験に基づいて、あなたが対処するいくつかの項目についてのチュートリアルを書きました (ほとんどは自分自身のリファレンスとして!):http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Python アプリケーションのビルドとインストールがいかに簡単であるかについての私のメモに感謝していただけると思います。 :)
これが役立つことを願っています!そして楽しいコンパイルです。
ティム・ジョーンズ
Ubuntu Linux でのソースからのアプリケーションのビルド/インストール
Ubuntu リポジトリには優れたアプリケーションがぎっしり詰まっていますが、リポジトリにない (または Debian パッケージがない) 必要な「必須」ツールに出くわすことがあります。リポジトリよりも新しいバージョン。職業はなんですか？ソースからアプリケーションをビルドする必要があります。心配する必要はありません。実際には、思ったほど複雑ではありません。ランクアマチュアからの私の経験に基づいて、いくつかのヒントがあります！ (この例では Ubuntu を使用していますが、一般的な概念は、Fedora などのほとんどの Unix/Linux ディストリビューションや、Windows の Cygwin プラットフォームにも適用できます。)
ほとんどのアプリケーションをソースからビルド (コンパイル) する基本的なプロセスは、configure --> compile --> install の順序に従います。これらのことを行う典型的な 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 gzip (GNU zip) の略で、一般的な Unix/Linux 圧縮形式です。同様に、.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 つの一般的なタイプのエラーがあります:
<オール>これらのそれぞれを見て、それらを解決する方法について説明します。
構成と構成エラー
ソース コード アーカイブ ファイルを抽出したら、ターミナルで、抽出したファイルを含むディレクトリに移動する必要があります。通常、このディレクトリ名はファイル名と同じです (.tar.gz を除く)。 または .tar.bz2 拡大）。ただし、ディレクトリ名がアプリケーションの名前だけで、バージョン情報がない場合もあります。
ソース ディレクトリで README を探します ファイルおよび/または INSTALL ファイル (または同様の名前を持つもの) です。通常、これらのファイルには、依存関係に関する情報など、アプリケーションのビルド/コンパイル方法とインストール方法に関する有用な情報が含まれています。 「依存関係」は、正常にコンパイルするために必要な他のコンポーネントまたはライブラリの単なる派手な名前です。
README を読んだら および/または INSTALL ファイル (およびアプリケーションに関連するオンライン ドキュメントを調べた場合)、config という名前の実行可能ファイル (ファイルに "x" パーミッションが設定されている) を探します。 または configure .ファイルに .sh などの拡張子が付いている場合があります。 (例:config.sh ）。これは通常、他のユーティリティを実行して、コンパイル用の「正常な」環境があることを確認するシェル スクリプトです。つまり、必要なものがすべてインストールされていることを確認します。
ヒント:これが Python ベースのアプリケーションである場合、構成ファイルではなく、setup.py という名前のファイルを見つける必要があります。 .Python アプリケーションは通常、インストールが非常に簡単です。このアプリケーションを root としてインストールするには (たとえば、Ubuntu では次のコマンドの前に sudo を置きます)、次のコマンドを実行します:
$ python setup.py install
あなたがする必要があるのはそれだけです。このチュートリアルの残りの部分をスキップして、アプリケーションの使用と楽しみに直接進むことができます。
ターミナルで構成スクリプトを実行します。通常、通常のユーザー アカウントで構成スクリプトを実行できます (実行する必要があります)。
$ ./config
スクリプトは、何をしているのかを示すメッセージを表示します。多くの場合、スクリプトは成功したか失敗したかを示し、失敗した場合は失敗の原因に関する情報を提供します。エラー メッセージが表示されない場合は、通常、すべてが正常に行われたと見なすことができます。
構成スクリプトのように見えるスクリプトが見つからない場合は、通常、アプリケーションが非常に単純で、プラットフォームに依存しないことを意味します。これは、提供されている Makefile が どのシステムでも動作するはずです。
例
このチュートリアルでは、Newsbeuter というテキストベースの RSS リーダーを使用して、アプリケーションのビルド時に発生する可能性のあるエラーの種類を示します。 Newsbeuter の場合、構成スクリプトの名前は config.sh です。 .私のシステムでは、config.sh を実行すると 、次のエラーが発生します:
[email protected]:~/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 に適したパッケージを見つけるには 開発パッケージ、apt-cache を使用できます Ubuntu のユーティリティ (および同様に、yum Fedora のユーティリティ):
[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite
このコマンドは結果の非常に大きなリストを返すため、どのパッケージが適切かを判断するために少し調査作業を行う必要があります。この場合、適切なパッケージは libsqlite3-dev であることがわかります .探しているパッケージに lib が含まれている場合があることに注意してください。 同じパッケージ名に -dev を加えたものではなく、プレフィックス .これは、多くの異なるアプリケーションで使用される可能性のある共有ライブラリを探している場合があるためです。 libsqlite3-dev をインストールするには 、ターミナルで典型的な apt-get install コマンドを実行します:
[email protected]:~/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 を実行すると、しばらくはうまくいきましたが、エラーが発生しました:
[email protected]:~/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 でソースからアプリケーションをビルドしてインストールするための、潜在的に反復的なプロセスです。これを数回やっただけで、自然に慣れていきます!
解決策 4:
./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」を追加して、検索するパスを追加できます。
複数のバージョンをインストールすることができ、古いバージョンに対してリンクされたソフトウェアは、古いバージョンに対してリンクされたままになります (Linux でバインディングを見つけるために ldd を実行します) が、新しいコンパイルは通常、システム上の動的ライブラリの最新バージョンをターゲットにします。
ほとんどのソフトウェアは、特に libtool を使用する場合、動的ライブラリを前提としているため、重要なアプリが静的に正しくビルドされないことがあります。
インストールされているライブラリを見つけるには、ls -l が最適です。
そして、それが私の情報不足です。パッケージをうまく扱う方法:わかりません。可能であれば、問題を回避するためにパッケージにまとめるようにしています.
解決策 5:
あなたの質問に少し答えるために、先日、インストールしたライブラリとバージョンを確認する良い方法を見つけました (これは 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