Autoconf/Automake/Libtool
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/05/23(火) 23:14:550002デフォルトの名無しさん
2006/05/23(火) 23:23:410003デフォルトの名無しさん
2006/05/23(火) 23:26:03/srcだの/binだのとりあえず作るようにして、無意味にいろいろライブラリ指定して、
そりゃもう、宇宙から来た人のような紀文。
0004デフォルトの名無しさん
2006/05/26(金) 22:06:310005デフォルトの名無しさん
2006/05/26(金) 22:46:450006デフォルトの名無しさん
2006/05/26(金) 23:23:12素直にMakeあたりの機能を拡張した方がよくね？
UNIXの精神とやらにそぐわないのかな
0007デフォルトの名無しさん
2006/05/27(土) 01:06:19と、マニュアルには書いてある。
0008デフォルトの名無しさん
2006/05/27(土) 01:39:17WebブラウザとHTMLエディタを一緒にするようなもんか
0009デフォルトの名無しさん
2006/05/27(土) 02:51:540010デフォルトの名無しさん
2006/05/27(土) 10:45:28違うだろ
makeファイル自動生成ツールだろ
0011デフォルトの名無しさん
2006/05/27(土) 17:00:01高々ビルドにこんな労力が必要なのは間違ってる
0012デフォルトの名無しさん
2006/05/27(土) 17:18:120013デフォルトの名無しさん
2006/05/27(土) 19:40:26autoconfが悪いんじゃない。
悪いのはUNIX環境の統一の無さ。
0014デフォルトの名無しさん
2006/05/27(土) 22:11:46もちろん、実際にプログラムが動くかどうかは別の話だけど。
0015デフォルトの名無しさん
2006/06/06(火) 23:39:22もっと安い本は無いものか
0016デフォルトの名無しさん
2006/06/07(水) 08:11:290017デフォルトの名無しさん
2006/08/13(日) 21:29:23ttp://www.ogis-ri.co.jp/otc/hiroba/technical/CppUnit/chapter3.html
のサンプルを試しています。
automakeがinstall-shをconfig以下に作るのはいいのですけどconfigure
の方のac_aux_dirが空のままで./configureを実行すると
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
となってMakefileが作られません。
aclocal --acdir=configも試したのですが
aclocal: configure.ac: 6: macro `AM_INIT_AUTOMAKE' not found in library
となってしまいます。今使っているのはautoconf 2.5xなのでサンプル
通りにはいかないのでしょうか？
configureでac_aux_dir=configと手動で設定してやれば./configureは
成功するのですが自動生成する方法はないでしょうか？
0018デフォルトの名無しさん
2006/08/13(日) 22:50:56とりあえず
$ autoreconf -vfi
とかしてみたり、
$ autoupdate
などで、autoconf-2.5xに対応してみては？
0019デフォルトの名無しさん
2006/08/14(月) 00:54:53やってみましたが効果なしです。
0020デフォルトの名無しさん
2006/08/14(月) 00:58:23>今使っているのはautoconf 2.5xなのでサンプル通りにはいかないのでしょうか？
2.59でうまくいくよ
dicegame-0.1.tar.gz展開してbootstrap実行してできたconfigureのac_aux_dirは
うちでは以下のようになってる
ac_aux_dir=
for ac_dir in config $srcdir/config; do
if test -f $ac_dir/install-sh; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/install-sh -c"
break
elif test -f $ac_dir/install.sh; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/install.sh -c"
break
elif test -f $ac_dir/shtool; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/shtool install -c"
break
fi
done
0021デフォルトの名無しさん
2006/08/14(月) 08:47:23どうやらconfigure.ac(configure.in)でAM_INIT_AUTOMAKE
の後にAC_CONFIG_AUX_DIRを書いていたのがいけなかったみ
たいです。
下のサイトにautoconf2.5xでは
「AC_INAC_INITの直後にAM_INIT_AUTOMAKE書く。」
と書いてあったので、それを実践していました。
http://www.saiin.net/~silphire/tips/autoconf.html
0022デフォルトの名無しさん
2006/08/15(火) 14:09:10を使うとテストが二回り行われてしまします。
それを防ぎたいのですけど何か設定とかあるのですか？
0023デフォルトの名無しさん
2006/10/31(火) 01:42:58GNU Make の後に読んでるからかやっと意味がわかった
前読んだときは書いてあることがまったくわからんかったのに・・・
「./configure;make;make install;」って今までおまじないでしかなかったのに・・・
みんなすごいね、中の人が何やってるか理解してつかってるの？
0024デフォルトの名無しさん
2006/10/31(火) 03:02:370025デフォルトの名無しさん
2006/11/01(水) 01:34:59002623
2006/11/06(月) 17:24:27for file
do
set fnord `echo ":$file" | sed -ne 's/^:￥//#/;s/^://;s/￥// /g;s/^#/￥//;p'`
・・・
ここのforループは何をしてるのでしょうか？
exec mkdir したところで mkinstalldirs の処理が終わってる気がするのですが？
#! /bin/sh -xv と デバッグ用echo, デバッグ用touch で追いかけてみても exec mkdir 以降の処理はやってない気がするのですが？？
なにか勘違いしているのだろうか？？？
0027デフォルトの名無しさん
2006/11/06(月) 21:16:27バージョンが古いのでは？
automake-1.9以降はそうなっていない。
002823
2006/11/06(月) 22:13:26確認してみたら automake-1.6 だった。MacOSX 10.4.8
そうか、古いのか・・・
002923
2006/11/07(火) 12:32:13このあたりのスクリプトの集合体なわけですか、なるほど
003023
2006/11/16(木) 14:03:140031デフォルトの名無しさん
2006/11/16(木) 21:27:33autotest関係はいまだ不安定かも。(2.60では大丈夫なのかな？)
というか、テスト全部にconfigure.ac書くのはめんどくさいかも。
不安定っていうのは、仕様変更が今後もありうるかもって意味であって、
動作が不安定ってわけじゃないので、安心してください。
0032デフォルトの名無しさん
2006/11/17(金) 01:04:41autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --output=aclocal.m4t
aclocal: macro `AM_PATH_PYTHON' required but not defined
aclocal: configure.ac: 22: macro `AM_GLIB_GNU_GETTEXT' not found in library
autoreconf: aclocal failed with exit status: 1
AM_PATH_PYTHONとかAM_GLIB_GNU_GETTEXTは、何に何を設定すればいいのでしょうか？
0033デフォルトの名無しさん
2006/11/17(金) 07:51:28> AM_PATH_PYTHONとかAM_GLIB_GNU_GETTEXTは、何に何を設定すればいいのでしょうか？
これらのマクロがインストールされていないため。
うちでは、
/usr/share/aclocal-1.10/python.m4 (automake-1.10)
/usr/share/aclocal/glib-gettext.m4 (glib-2.12.4)
にインストールされてる。
0034デフォルトの名無しさん
2006/11/17(金) 23:50:25ありがとうございました。
助かりました。
003523
2006/11/18(土) 21:03:37configure.in のひな形 configure.scan は autoscan で作れる。
autoscan はPerlのスクリプトである。
どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分
Perl わかんねからそっちの勉強しよ
0036デフォルトの名無しさん
2006/11/19(日) 09:34:20> どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分
info 読んだ方が楽だと思うけど、、、
後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。
003723
2006/11/19(日) 10:50:00＞info 読んだ方が楽だと思うけど、、、
確かに info autoscan 見たら詳しく書いてあった。
man autoscan だけしか見てなかったから動作基準が解らなかった。
# man の SEE ALSO 項目なんて全然意識してなかった
いままで
＞後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。
コレしてたんだけど in/out の動作原理が解らなかった.
ありがとう
003823
2006/11/21(火) 22:44:16Autoconf/Automake/Libtool この本は今イチよく解らない。でも代わりの良い本は解らない
ググったかんじでは
Automakeでmakeする
ttp://www.02.246.ne.jp/~torutk/cxx/automake/automake.html
ここが解りやすかった。あと マニュアルの日本語訳
ttp://www.geocities.jp/fut_nis/
0039デフォルトの名無しさん
2006/12/29(金) 17:33:58フォルダ配置がこのようにようになっていて
main
･ configure.ac
･ Makefile.am
--src folder
･ Makefile.am
･ xxx.c
--include folder
configure.ac, Makefile.am それぞれに
次レスのような内容を記述しています。
make をした後コンパイルには成功するのですが
なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ
コンパイルエラーは表示されないのでコンパイルには成功してると思うのですが･･･
どなたか対処法分かる方いませんか？
0040続き
2006/12/29(金) 17:34:30AC_INIT(xxx)
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_SRCDIR([src/xxx.c])
AC_CONFIG_HEADER([config.h])
AC_PROG_CC
AC_PROG_RANLIB
AC_PROG_INSTALL
AC_CONFIG_FILES([Makefile
src/Makefile])
AC_OUTPUT
------- Makefile.in --------
SUBDIRS = src
------- src/Makefile.in --------
INCLUDES = -I. -I.. -I../include
noinst_LIBRARIES = libxxx.a
libxxx_a_SOURCES = xxx.c
0041デフォルトの名無しさん
2006/12/30(土) 02:32:270042デフォルトの名無しさん
2006/12/30(土) 10:04:53> なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ
.libs 以下にできてるとか、、、というか、libtoolを使えば？
0043デフォルトの名無しさん
2006/12/30(土) 14:00:36一応確認するが、このコピペはconfigure.acとMakefile.amだよな?
configure.inとMakefile.inじゃなくて。
前者はともかく、後者は違っているとダメだと思うぞ。
で、それはそれとして。
make clean all >& make.log とでもしてログを吐き、
ログの中のコンパイルしている箇所を観察すれば、
どこにオブジェクトファイルを出力したのか(あるいはコンパイル自体していないのか)
わかるはず。
0044デフォルトの名無しさん
2006/12/30(土) 16:36:14.libs を探してみたのですが、ありませんでした。
autotoolsは今でもいっぱいいっぱいなので、
libtool はとりあえず後回しで・・・orz
>>43
失礼しました。Makefile.amです。
ﾛｸﾞも見てみたのですが、何が原因か全く分かりませんヽ(`Д´)ﾉｳﾜｧｧｧﾝ
このままだと埒が明かないので、
自分がコンパイルしようとしたサンプルプログラムをアップします。
http://wonder.bms.ms/tower/bin/sugoiuploader/img/037.zip
（>>39-40から内容を少し変えてあります）
make.log や Makefile も残しておいたので、
原因が分かる方がいたらほんとに教えてください。(人∀･)ﾀﾉﾑ
また、理由はよく分からないのですが gcc コマンドを手打ちして
オブジェクトファイルを作れば、メイクには成功します。
自分の実行したコマンドは build にあります。
0045デフォルトの名無しさん
2006/12/30(土) 18:40:59取れないので。取れた人よろしく。
004644
2006/12/31(日) 01:55:48別の所にアップし直しました。
http://gamdev.org/up/img/8499.zip
0047デフォルトの名無しさん
2006/12/31(日) 02:42:31src/Makefile.amの内容が40の（src/Makefile.in）とずいぶん違うようだが...
とりあえず実行権限が付与されてあるべきファイルで実際には付与されていないのがいくつかある
xxx/configure
xxx/depcomp
xxx/depcompを消してautomakeで作りなおしたらうまくいったよ
0048デフォルトの名無しさん
2006/12/31(日) 08:46:51autoconfのバージョンが違うので、うちではAC_INIT([xxx],[0.0.0])にしないとNG。
というか、AC_INIT か AM_INIT_AUTOMAKEのどちらかで
PACKAGEとVERSIONを指定しないと不味いはず。
# make dist なんてやると分かる。
src/Makefile.amで
noinst_LIBRARIES = libxxx.a
libxxx_a_SOURCES = xxx.c
をやりたければ、configure.acに
AC_PROG_RANLIB
を付けないと怒られた。
まあ、47が書いている実行権限の問題以外はゴミみたいな話だが。
ちなみに、
automake (GNU automake) 1.10
autoconf (GNU Autoconf) 2.61
な環境。
0049デフォルトの名無しさん
2006/12/31(日) 14:46:53>>47
出来ました！
実行権限の問題だったのですね
ありがとうございます。
>>46
バージョンの方も指定するようにしました。
いろいろとありがとうございます。
ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:*
0050デフォルトの名無しさん
2006/12/31(日) 14:47:520051デフォルトの名無しさん
2007/01/13(土) 16:34:59ソースがincludeしているヘッダファイルが修正されたときに、そのソースを自動で
コンパイルし直す様なMakefileを作るにはどうすれば良いでしょうか？
0052デフォルトの名無しさん
2007/01/13(土) 16:50:38普通にそのようなMakefileができますが...
0053デフォルトの名無しさん
2007/01/13(土) 16:56:12自動でやってくれていました。
0054デフォルトの名無しさん
2007/01/13(土) 16:57:51依存している物で試したら上手く処理してくれましたorz。
0055デフォルトの名無しさん
2007/04/02(月) 07:17:53autotoolsを使ってプログラムを作ろうとしています。
プログラム、main を作ろうとし、
mainはobjA.Oをリンクさせる必要があります。
さらに、objA.oはobjB.oをリンクさせる必要があります。
#このようなイメージです
main -依存-> objA.o -依存-> objB.o
このような場合、Makefile.amには
bin_PROGRAMS=objB objA main # objA.oの.oを付けるとエラーが出てしまったのでつけてません
# objBを生成するための
objB_SOURCES=sourceb.cpp
# objAを生成するための
objA_SOURCES=sourcea.cpp
objA_LDADD=objB
# mainを生成するための
main_SOURCES=main.cpp
objA_LDADD=objA
このように書かなくてはならないのでしょうか？
0056デフォルトの名無しさん
2007/04/02(月) 10:30:33根本的に、autoconf、libtoolは移植性
automakeはパッケージ作成のためなので、
外部のオブジェクトとリンクするパッケージでは、
autotoolsを使うメリットは無いでしょう。
そういうわけでは無く、autotoolsの勉強なら、
パッケージ構成を見直した方が良いと思います。
0057デフォルトの名無しさん
2007/04/03(火) 12:32:21了解しました。ちょっと見直してみます。
さらに質問で悪いのですが、
prog_SOURCES=a.c b.c c.c
とした場合、
a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
どのようにMakefile.amに書けばよいのでしょうか？
0058デフォルトの名無しさん
2007/04/06(金) 02:39:15>a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
それぞれ別々のオプションをつけたいってこと？
info の Per-Object Flags Emulation を参照。
0059デフォルトの名無しさん
2007/04/07(土) 11:08:22ありがとうございます
0060デフォルトの名無しさん
2007/04/07(土) 18:28:09また質問なのですが
./src
source1.cpp
./subsrc
source2.cpp
という構成で、./srcにlibtest.aを作りたい。という状況です。
この場合、./src/Makefile.amに
libtest_a_SOURCES=source1.cpp subsrc/source2.cpp
と書くしか方法は無いのでしょうか？
./src/Makefile.amには./srcにあるファイルを、./src/subsrc/Makefile.amには./src/subsrcにある
ファイルを記述した方が管理が楽だろうと考えているのですが・・・
0061デフォルトの名無しさん
2007/04/14(土) 16:23:55本当にやりたいことは何なのか整理した方がいいと思う。
src 以下のソースを全部まとめて libtest.a を作りたいんだよね？
libtest.a に対する指定で subsrc に対して言及しなければいけないのは当然。
subsrc 以下のソース「全て」を記述するのが面倒だ、という意味で、libtool を使うのも辞さないというなら
# src/subsrc/Makefile.am
noinst_LTLIBRARIES=libsubsrc.la
libsubsrc_la_SOURCES=source2.cpp # とか色々
# src/Makefile.am
lib_LIBRARIES=libtest.a
libtest_a_SOURCES=source1.cpp
libtest_a_LIBADD=subsrc/libsubsrc.la
で、いけるんじゃない？
0062デフォルトの名無しさん
2007/06/24(日) 22:46:03開発途中は自分でmakefile作って、ある程度完成したらその段階で./configure でmakefile を作ってもらうほうがいいの？
0063デフォルトの名無しさん
2007/06/24(日) 22:58:31自分で書いた方が多分楽です。
配布のときに make dist できる程度かな？
0064デフォルトの名無しさん
2007/06/25(月) 02:27:470065デフォルトの名無しさん
2007/06/27(水) 01:48:27複数の環境でビルドすることを考えるなら Autotools を使う方が楽だろう。
恐らく、そんな質問をしている時点では自前で Makefile を書いた方が楽だ。
0066デフォルトの名無しさん
2007/09/17(月) 20:14:26foo-1.0/test/b.c があって、a.c は -O2 で、b.c は -O0 でコンパイルしたいと思っています。
test/Makefile.amに、
bin_PROGRAMS=b
b_CFLAGS=-O0
と書いてみたのですが、
gcc -O0 -O2 (中略) b.c
のようにコンパイルされてしまい(上から渡ってくる?CFLAGSの-O2がb_CFLAGSより後ろにきて
しまって)最適化がかかってしまいます。test/Makefile.amに
CFLAGS=
という行を追加すればいいかともおもったんですが、これもautomakeに
`CFLAGS' is a user variable, you should not override it; などとと怒られてしまいます。
test/Makefile.amにAM_CFLAGS=-O0 を書き足しても、b_CFLAGSと同じ効果しか得られません。
どうしたらよいか教えていただけませんか？
0067デフォルトの名無しさん
2007/09/18(火) 01:16:57CFLAGSなどはユーザ(パッケージを使う人)が制御するものなので、
パッケージメンテナが強制してはならない。
Makefile.amはパッケージメンテナが書くものなので、
その中で最適化オプションを強制するのは厳禁。
これを体現するため、ユーザ指定のCFLAGSは必ず最後に付加されることになってる。
詳しくは automake.info の FAQ の "Flag Variables Ordering" でも読んで。
回避するハックがあるかどうかは知らないが、お勧めしない。
ユーザとしてその場で行いたいだけなら、次のようにすればOK。
cd test; make CFLAGS=-O0 b.o
0068デフォルトの名無しさん
2007/09/18(火) 01:25:020069デフォルトの名無しさん
2007/12/31(月) 17:07:13'wx-config --cppflags'の出力されたものを
作成ファイルのMakefile.am内オプションに追加したいのですが
いったいどうやればいいのですか？
ついでに、何度か同じことをする必要があるので
共通の変数か何かに設定できるとうれしいです。
0070デフォルトの名無しさん
2008/01/26(土) 23:26:580071デフォルトの名無しさん
2008/03/09(日) 17:46:070072デフォルトの名無しさん
2008/03/09(日) 17:51:090073デフォルトの名無しさん
2008/06/12(木) 00:21:03それとも、メジャーなディストリでビルドできればいいよくらいのスタンスなら、
自前MakefileでもOK？ みなさんどうお考えですか?
0074デフォルトの名無しさん
2008/06/12(木) 01:14:19Linux だけが対象だと auto-tools である必要はないと思われる。
「auto-tools は GNU 教への帰依の度合いを計る試金石として存在している」
と言う話を, どこかで効いたような気がするw
0075デフォルトの名無しさん
2008/06/12(木) 02:38:37とりあえず配布してみれ．それが役に立つアプリで他のOS環境でも
動かしたいと思う人がいればきっとその人がautotoolizeしてくれるよ．
0076デフォルトの名無しさん
2008/06/12(木) 13:39:40#ifdefとかが絡んでくるようになると
autotoolsが枠組みを最初から用意してくれているのはそれなりに便利。
0077デフォルトの名無しさん
2008/06/12(木) 14:20:120078デフォルトの名無しさん
2009/02/13(金) 13:10:57AC_CHECK_LIB だとうまくいきません。（名前空間やname manglingの影響？）
どうやるのがよいでしょうか？
0079デフォルトの名無しさん
2009/02/13(金) 20:35:17多分 AC_LANG 辺りじゃないかと思うが、どううまくいかないのか書かないと分からないと思われ。
config.log くらいは確認してる？
0080デフォルトの名無しさん
2009/02/13(金) 23:36:22あ、うまくいかないというのは、ライブラリはインストールされているのに、
ないと判断されてしまうということです。
関数をmain でやったら、うまくいってるっぽいですが、これでいいんですかね？
0081デフォルトの名無しさん
2009/02/14(土) 09:31:56だからさ、エスパーきぼんぬしたいんじゃなければ何をどうやってどうなったかもう少しきちんと書こうぜ。
これで、第三者がまともな回答ができると思ってんの？
このライブラリの有無の判別がしたくて、configure.ac にはこう書いて、config.log の該当部分ではこんなコードと
出力になっています、まで書いて当然レベルじゃね？
もっとも config.log の該当部分のソースとコンパイラ(orリンカ)が出力してるエラーを見れば質問するまでもなく
理由と対処は見えると思うけど。
0082デフォルトの名無しさん
2009/02/14(土) 19:07:2880みたいのはもともと脳味噌壊れてるので言ってもわからん気がするぞ。
0083デフォルトの名無しさん
2009/03/10(火) 20:27:42AC_CHECK_FUNCS([clock_gettime])
とAC_CHECK_FUNCSを使ってみたのですが、発見してくれません。
AC_CHECK_DECL を試してみたのですがこちらも駄目でした。
実際には、手元のLinux （CentOS 5） では
$ grep clock_gettime /usr/include/time.h
extern int clock_gettime (clockid_t __clock_id, struct timespec *__tp) __THROW;
と存在しています。
config.log を見てみたんですが、判定に使っている conftest.c で、<time.h> をインクルード
してないのが理由のようです。 clock_gettime()を発見してもらうには
どうしたらいいのでしょうか？
008483
2009/03/10(火) 20:29:14$ autoconf --version
autoconf (GNU Autoconf) 2.62
0085デフォルトの名無しさん
2009/03/10(火) 22:06:34AC_TRY_COMPILE 使ってヘッダ指定すればいいんじゃね？
008683
2009/03/10(火) 23:18:52ども
なんかマニュアル見たらobsoleteだって書いてあったので、
↓のようにしたらできました。ありがとうございました。
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM([[ #include<time.h> ]],
[[(void) &clock_gettime;]])],
[AC_DEFINE([HAVE_CLOCK_GETTIME],
[1],
[Whether clock_gettime() exists.])],
[])
0087デフォルトの名無しさん
2009/04/10(金) 20:24:28■ このスレッドは過去ログ倉庫に格納されています