autoconf を実行していて、configure で SHELL を「/bin/sh」に設定しています。これは大きな問題を引き起こします。autoconfのためにSHELLを強制的に「/bin/bash」にする方法は?
これを osx で実行しようとしていますが、Linux で動作しています。Linux は SHELL=/bin/bash を使用しています。osx のデフォルトは /bin/sh です。
SolarisとGCCで同様の問題があり、「標準」の手法を使用しています。
CONFIG_SHELL=/bin/bash ./configure ...
(または、実際には/ bin / kshを使用しますが、CONFIG_SHELL env varを設定すると、autoconfスクリプトにどのシェルを使用するかを指示できます。)
gitとgdのconfigureスクリプト(たまたま抽出されたもの)をチェックして、これがGCC固有のenv変数ではないことを確認しました。
「大きな問題」とは?autoconf は、非常に多くのシェルで動作する構成スクリプトを生成するのに非常に苦労します。autoconf が書いている移植性のない構文の例がある場合は、autoconf メーリング リストに報告してください。一方、あなたが経験している問題が、configure.ac 内の独自のシェル コードが移植可能でない結果である場合 (たとえば、bashisms を使用している場合)、解決策は、移植不可能なコードの使用をやめるか、またはユーザーは構成時に SHELL または CONFIG_SHELL を明示的に設定できます。
発生している問題は、configure を実行しているユーザーの環境にあるようです。Linux では、ユーザーは SHELL を /bin/bash に設定していますが、OS X では /bin/sh に設定されています。autoconf によって生成された configure スクリプトは、それが実行されているシェルのいくつかの初期テストを行い、提供されたシェルに特定の機能が欠けている場合、別のシェルを使用して再実行を試みます。ただし、configure.ac に移植性のないシェル コードを導入している場合は、autoconf の主な哲学の 1 つ、つまり、configure スクリプトは移植可能でなければならないという原則に違反しています。本当にシェル コードで bashisms を使用したい場合は、ユーザーが構成スクリプトへの引数として SHELL=/bin/bash を渡す必要があります。これは autoconf のバグではありませんが、多くの人はプロジェクトのビルドのバグだと考えています。
Autoconf は、「どこでも」実行できるスクリプトを生成することにより、移植性の問題を解決することになっています。そのため、次のような奇妙なコードが生成されます。
if test X$foo = X ; then ... # check if foo is empty
それよりも:
if [ "$x" = "" ] ; then ...
その種の粗雑なコードにより、これらのスクリプトを古代の Ultrix システムなどで実行できるようになった可能性があります。
シェルの違いが原因で構成スクリプトが実行されないのは、10 リットルのガソリンと 3 つのスペア タイヤを持ってフォーミュラ 1 レースに参加するようなものです。
Autoconf を使用して構成スクリプトを開発していて、シェルが Bash か OSX シェルかに敏感な場合は、何か間違っているか、Autoconf 担当者が何かを壊しています。それがあなたからのものである場合は、スクリプトに追加するシェル部分を移植可能にすることで修正してください。
SHELLはどこに設定されていますか?/bin/bash が必要な場合、/bin/sh で何が実行されていますか?
configure スクリプトは、実際に存在するひどく壊れた Bash 以外のシェルであっても、どこでも実行できるようになっています。
編集:問題は正確には何ですか?
別の編集: おそらく、このようなスクリプト自体を再実行したいでしょう。おそらくバグがあります:
if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then
exec /bin/bash -c "$0" "$@"
fi
ln -f /bin/bash /bin/sh
:-P (いいえ、それは深刻な答えではありません。システムにホースをかけないでください!)