問題タブ [autoconf]

私は GNU/Linux で C++ プロジェクトに取り組んでおり、Autotools を使用して IBM Informix のライブラリの存在と使いやすさをテストする方法、つまりconfigure.in. 私は Autotools の経験がないので、基本的にはプロジェクトのconfigure.in et al. から拾っています。スクリプトと、変更が必要だと感じる場所のコピーと変更。IOW、私は の既存のテキストから適応してきましたconfigure.in。

これまでのところ、特定のライブラリが存在し、使用可能かどうかをテストするためAC_CHECK_LIBに inをうまく使用してきました。configure.inしかし、これはクラスなどではなく、関数を持つライブラリでのみ機能するようです。つまり、これは Informix のlibifc++.soライブラリをテストするときに失敗します。

ITString::ITStringなどの他の組み合わせも試しました。

Informix の API に「純粋な」関数 (つまり、C++ クラスでコンテキスト化されていない関数) は見つかりませんでした。AC_CHECK_LIBしたがって、このコンテキストで使用する方法があるか、この特定の用途のための別のautoconf/ configure.in「コマンド」があることを願っています。

フィードバックをお寄せいただきありがとうございます。

プロジェクトのビルド方法または autoconf を使用したライブラリの作成方法を知っています。

私が達成したいのは、静的ライブラリを生成し、このライブラリを使用して、1 回の構成/作成/作成インストールの実行でプロジェクトをビルドすることです。

一部のソース ファイルをライブラリに配置し、残りをこのライブラリを使用してコンパイルする必要があります。

makefile.am ファイルと configure.ac を変更して機能させるにはどうすればよいですか?

更新:最初の問題は解決され、2 番目の問題はこの投稿の下部に記載されています。

UPDATE2: 2 番目の問題も解決されました。

非常に単純な GTK+2 C アプリケーション用の GNU ビルド ツール (autoconf/automake) のセットアップについて学習しようとしています。このチュートリアルとサブディレクトリを扱うこのチュートリアルに従いましたが、親ディレクトリの Makefile が生成されているにもかかわらず、ソース ディレクトリ (src サブディレクトリ内) が Makefile を生成しないという問題が発生しています。

まず、私のフォルダ構造は次のとおりです。

重要なファイルの内容は次のとおりです。

app/configure.ac:

app/Makefile.am:

app/src/Makefile.am:

次のコマンドを実行すると、次のようになります。

チェックすると、アプリのメイン フォルダーには Makefile と Makefile.in が含まれていますが、src フォルダーには Makefile.am しかありません。何か案は？

更新: adl で言及されている変更を行いました。つまり、AC_CONFIG_FILES コマンドから角かっことコンマを削除し、AM_INIT_AUTOMAKE コマンドからアプリ名/バージョンを削除しました。また、src/Makefile.am の app_LDADD コマンドを app_LDFLAGS に変更しました。これにより、configure を通過できないという最初の問題は修正されましたが、現在は gtk ライブラリを探していません。make を実行すると、次のような結果が得られます。

pkg-config で得られるものは次のとおりです。

src/Makefile.am で何か間違ったことをしていると確信していますが、何が原因かわかりません。それが役立つ場合、私の構成スクリプトは gtk ライブラリを探していないようです。

更新 2:

したがって、update1 の問題の基本的な解決策は、configure.ac ファイルに次のチェックを追加する必要があるようです。

これは、AC_PROG_CC の下のプログラム セクションのチェックに追加されます。これが行うことは、gtk+-2.0 ライブラリをチェックするよう configure に指示することです。大文字の GTK は任意の変数名のようで、CFLAGS、LIBS、および LDFLAGS (およびおそらくそれ以上) が動的に追加されるため、PACKAGE_* 変数を生成できます。AC_SUBST は Makefile.am の PACKAGE* 変数にアクセスできるようにするようです。参考までに、-export-dynamic フラグが追加されて、glade/gtkbuilder ファイルを使用できるようになりました (他にも理由があると思いますが、私はまだ非常に基本的なレベルの理解に留まっています)。

src/Makefile.am には、次のものが必要です。

これは、基本的な gtk+-2.0 C アプリに必要なすべてのようです。autotools を使用する C gtk アプリをセットアップするための簡単なチュートリアルを書くきっかけになりました。この分野では、最近の初心者向けのドキュメント/情報が明らかに不足しています。

現在、autotoolset プロジェクトには 10 個のテストがあります。src/ ファイルの 1 つに変更を加えて再コンパイルするたびに、各テストが再構築されてリンクされます。これは私の開発時間にかなりの影響を及ぼし始めています。

GNU autotoolset を使用してバイナリ プログラム、テストなどを条件付きでビルドする最良の方法は何ですか? たとえば、test/check_curl_requestheaders.cc で作業していて、変更を加えた場合、ライブラリを再コンパイルしてからその 1 つのテストだけを再コンパイルし、他のバイナリは一切コンパイルしません。

automake 条件 (WANTS_XXX など) を使用することについての言及を見ましたが、それが私が探しているものであるとは 100% 確信が持てませんし、autoconf によってどのように設定されるかもわかりません。

私は、次のような結果になることを期待しています。

また

ポインタ？

編集私はすべてのメイクの前に構成を行っていません。に変更を加えると、期待どおりcheck_curl_requestheadersにのみが再構築されます。check_curl_requestheaders問題は、ライブラリの RequestHeaders 部分に取り組んでいて、src/curl/requestheaders.cc のように変更すると、check_curl_requestheaders. それには時間がかかりすぎます。それは私が避けようとしていることです。多数のバイナリがある場合、そのうちの 1 つだけを再構築する方法はありますか?

1 つのプロジェクトで、2 つnoinst_PROGRAMの が定義されています。そのうちの 1 つは問題なく動作しますが、もう 1 つは次のメッセージを表示しています。

/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar: シンボル検索エラー: /home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar: 未定義のシンボル: _ZN5gdata7service7ServiceD1Ev

Makefile.am ファイルを調べましたが、見逃したものは見つかりません。アプリケーションは正しくコンパイルされるので、これはヘッダー ファイルが正しく検出されたことを意味すると推測していますが、何らかの理由で mygdata::service::Serviceが src/libgdata.la ライブラリに含まれていません。

私の仮定が正しい可能性はありますか？src/libgdata.la ライブラリで定義されている他のクラスは使用できるようです。「make」の出力は、Service.cc ファイルが正しくコンパイルされていることを示しています...最終的なライブラリに含まれていることを確認するためにどこを参照すればよいですか?

編集：

これまでに提供された回答に基づいて、これをさらにデバッグすることができました。

デストラクタは Service.cc で定義されています。ヘッダー ファイルでデストラクタに本文を指定すると、すべて正常に動作します。

デストラクタが「機能する」ようになったので、Service.cc で定義されている他のメソッドが見つからないことに遭遇しました。

@ephemient の方法を使用すると、これらのシンボルが実際にライブラリに含まれているように見えます。または、出力を間違って読んでいますか?

私の src/Makefile.am は次のようになります。

私の src/gdata/service/Makefile.am は次のようになります。

私の test/Makefile.am は次のようになります。

gdatayoutube は問題なく動作します。サービス（ gdata/client/libgdata_gdata_client.la ）の代わりにクライアントディレクトリのコードを使用するのは古いコードです...クライアントがサービスからセットアップされる方法に違いはありません。:-/

**編集＃2：##

これがどのように起こったのかはわかりませんが、問題は見つかったと思います。テスト アプリは、src/.

私はこれをさらに調査し、別の機会に他の質問をするかもしれません。

autoconf / automakeを使用した非常に複雑な（C ++）プロジェクトがあります。これには、いくつかの「生成された」ファイル（foo.yy-> foo.cc）が含まれています。実際のビルドは、さまざまなプラットフォームで「制御スクリプト」（概念に精通している人のためのGentoo .ebuild）を使用して行われます。

現在、ターゲットプラットフォームの1つはfoo.yy-> foo.ccステップを適切にサポートしておらず、Linuxボックスで生成されたfoo.ccファイルを使用する必要があります。

今、私はこれについて行く2つの方法があります：

1）foo.ccをプロジェクトリポジトリにチェックインし、configure.in（またはその他）にパッチを適用してfoo.yy / foo.ccにタイムスタンプチェックを含め、問題のターゲットで古いターゲットで実行すると、わかりやすいエラーメッセージを生成します。 foo.cc;

2）foo.ccを制御スクリプトリポジトリにチェックインし、スクリプト制御のタイムスタンプを取得して、エラーメッセージを表示します。

2）問題ありませんが、foo.ccを配置するのに適切な場所ではないと思います。

一方、私はautoconf / automakeについてあまり知りませんし、configure.in（またはどこでも）にタイムスタンプチェック/エラーメッセージを実装する方法を知りません。

あなたの提案は何ですか、そしてここの誰かが解決策1）について行く方法を知っていますか？

編集：解決策3）を使用して解決し、foo.yy->foo.ccステップ自体を実行できるようになるまで問題のあるターゲットボックスを微調整します。私の問題は解決しました。

しかし、私は質問を開いたままにしておきます-autoconf / automakeでタイムスタンプチェック/わかりやすいエラーメッセージを実行する方法は？

libgdataいくつかのテストとインストールされていないプログラムを含むライブラリを作成しています。ライブラリを一度インストールすると、プログラムがローカルバージョンではなく、インストールされたバージョンにリンクしているように見えるという問題が発生しています../src/libgdata.la。

何が原因でしょうか？私はひどく間違ったことをしていますか？

これが私のtest/Makefile.am見た目です：

（libapiutillibcurlとlibxml ++を処理するためのいくつかのヘルパーのものを持っている別のライブラリです）

したがって、たとえば、何もインストールせずにテストを実行すると、すべてが正常に機能します。ローカルで変更を加えることができ、それらはすぐにこれらのプログラムによって取得されます。

パッケージをインストールすると、これらのプログラムはコンパイルされますが（実際には、ヘッダーをローカルで検索しているように見えます）、プログラムを実行すると、シンボルの欠落について文句を言います。

私の知る限り、make出力に基づいて新しく構築されたライブラリ（../src/libgdata.la）とリンクしているので、なぜこれが発生するのかわかりません。インストールされたファイルを削除すると、src/*へのローカルの変更は問題なく取得されます。

以下にgdatacalendarのmake出力を含めました。

ヘルプ。:)

アップデート

addCommonRequestHeader()メソッドなしでライブラリをインストールした後、Serviceクラスにメソッドを追加したときにカレンダープログラムを実行しようとすると、次のメッセージが表示されaddCommonRequestHeader()ます。

変数の設定を試みるというEugeneの提案$LD_LIBRARY_PATHは役に立ちませんでした。

更新2

私は2つのテストを行いました。まず、dev-installディレクトリ（--prefix）を吹き飛ばした後にこれを行いました。その場合、が作成されますtest/.libs/lt-gdatacalendar。ただし、ライブラリをインストールすると、test/.libs/gdatacalendar代わりにライブラリが作成されます。lddの出力は、1つの例外を除いて、両方で同じです。

これにより、ある場合にはlt-gdatacalendarが作成され、別の場合にはgdatacalendarが作成される原因は何でしょうか。

libgdataでのlddの出力は次のとおりです。

configure 引数に応じて、Intel コンパイラーまたは gcc/g++ でコードをコンパイルしたいと考えています。これは可能ですか？これを実現するには、configure.ac および Makefile.am ファイルに何を入れる必要がありますか?

すべてのUNIXシステムでコンパイルしたいコードがありますが、-m64 iが使用可能であり、それが機能する場合は、configureスクリプトでそれを使用する必要があります。autoconfに-m64が機能するかどうかを確認し、機能する場合はそれを使用するにはどうすればよいですか？