autotoolsからプラットフォームライブラリが静的か動的かを調べる方法は？

Question

設定 autotools（autoreconf -ivと./configure）を使って正しいmakefileを生成します。私の開発マシン（Fedora）では、すべて正常に動作します。 make checkの場合はlibcheckのライブラリを使用し、autotoolsの場合はLibtoolsを使用します。 Fedoraでは、チェックのためのライブラリは動的です：libcheck.so.0.0.0またはそのようなものです。できます。

号 私はgithubの上の私のレポへのコミットをプッシュし、プルリクエストを行うと、結果はプラットフォームとしてのUbuntuを使用していますトラヴィスCI上でテストされています。 Ubuntuでは、libcheckはスタティックライブラリです：libcheck.aとlibcheck_pic.aです。

トラヴィスがないときに、私は次のエラーメッセージを取得メイクチェック：共有オブジェクトを作るとき

/usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../.. /../libcheck.a(check.o): relocation R_X86_64_32 against .rodata.str1.1' は 使用することはできません。私は何とかconfigureが私は必要なもののライブラリを決定できるようにする必要があるということはどの-fPIC`

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../libcheck.a: could not read symbols: Bad value

で再コンパイルします。私はUbuntuのlibcheck_pic.aとFedoraのlibcheck.soが必要だと思う。誰は、libtoolを使用してconfigure.ac、テスト/ Makefile.amにこれを統合する方法

質問 を知っていますか？私は、autotoolsの生活の方法に沿って滞在することを好むだろう。

googleを使用して使用できる情報が見つかりませんでしたが、静的と動的の違いについて何か質問があります。

誰かが私を正しい方向に向けることができたのか、それともすでに解決しているのではないでしょうか？

Answer 1

私はCIシステムで使用したいライブラリがlibcheck_pic.aであると思っています。その名前は、内部のルーチンがポジションに依存しないコードとしてコンパイルされていることを示しています。行う。

問題にアプローチする1つの方法は、libcheck_picが利用可能であればそれを使用し、それ以外の場合はlibcheckにフォールバックすることです。 Autotoolsベースのビルドシステムを構成するのはそれほど難しいことではありません。その後、適切なライブラリ名を出力変数に記録し、それをあなたの（自動）makeファイルで使用します。

AutoconfのSEARCH_LIBSマクロは、この種の優先順位付けされたライブラリ検索要件に特に役立ちますが、LIBS変数を変更するという副作用があります。それにもかかわらず、それは動作させることができます。この例では、それを行うかもしれないような何か：

LIBS_save=$LIBS 
AC_SEARCH_LIBS([ck_assert], [check_pic check], [ 
    # Optional: add a test to verify that the chosen lib really provides PIC code. 

    # Set LIBCHECK to the initial substring of $LIBS up to but excluding the first space. 
    LIBCHECK=${LIBS%% *} 
    ], [ 
    # or maybe make it a warning, and disable your test suite when libcheck 
    # is not available. 
    AC_MSG_ERROR([A PIC version of libcheck is required]) 
    ]) 
AC_OUTPUT([LIBCHECK]) 
LIBS=$LIBS_save 

は、私はあなたが作る側で$(LIBCHECK)で何をすべきか知っていると推定します。

libcheckのPIC版がない場合、makeまたはおそらくmake checkまでは見つからないという制限があります。これは望ましくないことであり、Autoconfコードを追加して、それが十分に望ましくない場合にその状況を検出することができます。

---

は全く異なるアプローチとして、あなたは（適切な *_LDFLAGS変数に -staticを追加）静的テストを構築を検討できます。もちろん、これには反対の問題があります。ライブラリの静的バージョンが利用できない場合、ビルドまたはテストは失敗します。また、まだ実行していない場合は、独自のコードの静的バージョンを構築する必要があります。さらに、テストされる静的バージョンも必要です。

最大の柔軟性を得るには、これらの2つのアプローチを組み合わせることを検討してください。フォールバックを設定したり、静的コードとPICコードをテストするための別個のターゲットを設定したり、どちらか（おそらく両方）がビルドシステムで使用可能なライブラリでサポートされているかを検討することができます。