Autoconf,Automakeについて

1 名前：名無しさん＠お腹いっぱい。 [02/04/11 05:24.net] 奥深さの前に使い方がさっぱり分からん。教えて下さい。 関連サイトは>>2 101 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 17:02.net] >>100 ああ、Makefile.amの間違いだよな。 102 名前：名無しさん＠お腹いっぱい。 [03/12/27 17:02.net] >>99 ありがとうございます。 ところでprefixを/usrにするとどういうデメリットがあるのでしょうか？ 103 名前：名無しさん＠お腹いっぱい。 [03/12/27 17:03.net] >>101 ごめんなさい。その通りMakefile.amの間違いです。 104 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 18:11.net] >>102 /usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。 /usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。 Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い (衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。 105 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 19:12.net] OSの一部として配布されるもの以外は/usrに入れないのが当り前です。 システム上重要というだけでなく、そのOSを使っている人の間で構成が 一致しているからでもある。 Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ うのも納得できる。 >>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。 106 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 19:44.net] 寄せ集めっつーか、大多数のLinuxディストリにはbase systemと いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール したらそれもbase systemの一部だ」みたいなノリなんだろうね。 107 名前：ヽ(´ー`)ノ mailto:sage [03/12/27 20:30.net] >>105 Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。 最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。 特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。 > Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? これは、もはや昔話だよもん。 108 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/01/07 17:28.net] 一度rpmにするものは/usrにしてる。 109 名前：名無しさん＠お腹いっぱい。 [04/02/01 23:20.net] libtool.m4に入ってるチェックで、Fortranコンパイラを勝手に探したり、 maximum length of command line argumentsとか言ってCPU食うのを やめさせたいんですけど。そういうACマクロはないんでしょうか？ 110 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/01 23:29.net] >>109 「勝手」にチェックする m4 なんてない。 configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。 気に入らなきゃチェックしてるところを外せ。 # それでまともにコンパイルできるとは思えんが。 111 名前：名無しさん＠お腹いっぱい。 [04/02/01 23:36.net] えーと言い方が悪かったですが、AC_PROG_LIBTOOLマクロを使うと ほとんどのパッケージには不要なはずのチェックが盛りだくさんに はいるわけです。 とりあえず全部チェックしておけばどんな場合にも対応できるってこと なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、 そういうマクロあります？って話です。 libtool.m4が洗練されてないと言えばそれまでですがね。 112 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/01 23:53.net] 古いlibtool使うしかないのでは？ 113 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/02 19:06.net] >>109 AC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、 自分でlibtool.m4を書き換えちゃえば？ うまく動く保証は無いし、libtool使う意味も減ると思うけど。 移植性考えないんならlibtool使わなくてもいいんじゃないかな？ 114 名前：名無しさん＠お腹いっぱい。 [04/02/04 11:21.net] 移植性を考える考えないの二択ではないでしょう。全プラットフォームの 全項目を保証する気なんてないし、不可能ですから、どこまでチェック するかの問題ですね。AutoconfにしてもLibtoolにしても。 ですから「移植性考えないならlibtool使わなくていい」なんてのは極論です。 このチェックに関して言えば、ソースのビルド中にコマンドラインの 最大長を超えるコマンドは分割実行するようになっているみたいですが、 環境によっては数分以上かかるようなチェックをするより、4096とか 小さい値を決めうちしたほうがいいですね。実際そうしましたが。 コマンドに4096バイトも入らないプラットフォームは問題外ですから 無視でよいです。デフォルトがチェックになってるのは仕方ないですが。 115 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/04 12:01.net] 外してたら済まんが、ac_cvなんとかでスキップできんの? 116 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/04 14:03.net] たかだか AC_LIBTOOL_SYS_MAX_CMD_LEN のチェックぐらいで数分もかかる プラットホームは俺の中で問題外なんだけどなｗ 何のために libtool 使ってんのか分からんよ。 117 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/04 19:48.net] >>114 configure時の話なら、config.siteじゃできんかな？ lt_cv_sys_max_cmd_lenがキャッシュにあれば良さそうなんで、 test "$lt_cv_sys_max_cmd_len" = NONE && lt_cv_sys_max_cmd_len=4096 みたいな内容を書いとけばいいかもね。 # 試してないんで違うかもしれん。 # 今、バージョンの不一致でautotoolsがうまく動かない(泣) 118 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/04 20:02.net] autoconfのドキュメント読んでたら、 $ ./configure --lt_cv_sys_max_cmd_len=4096 でいけるかもしれんような気がした。 しかし、試せない。。。 119 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/08 09:35.net] やっと試せた。 >>118 > $ ./configure --lt_cv_sys_max_cmd_len=4096 ではなく、 $ ./configure lt_cv_sys_max_cmd_len=4096 だね。 120 名前：名無しさん＠お腹いっぱい。 [04/03/04 19:46.net] libtool関係の質問はOKですか?>このスレ 121 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/03/04 19:55.net] すぐ上でされてるみたいだけど、とりあえずやってみれば？ 問題があれば誘導されるでしょ。 122 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/03/04 20:01.net] configureのコストが、高機能になればなるほどデカクなってきてる わけですが、これらを動的にチェックするんじゃなくて静的にデータ ベースのようなもので持たせることはできないですかね。とはいっても 何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう わけでなかなか難しいんだろうけど。 123 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/03/04 20:07.net] >>122 そのためにはconfig.siteを使えばいいと思うんだけど。 124 名前：120 mailto:sage [04/03/04 21:15.net] >>121 では、御言葉に甘えて。 ちょっとした理由で、安定版のXFCE4が入ってるシステムにCVS版のXFCE4を別にインストールしようと思ってます。 #安定版:パッケージで入れてるので/usr以下 #CVS版:ソースからコンパイルで/opt/xfce4以下 まず、libxfce4utilをインストールしました。(これで、libxfce4util.soは/usr/libと/opt/xfce4/libに存在） 次にlibxfcegui4とlibxfce4mcsをコンパイルしたのですが、libxfcegui4では、リンクの際に /bin/sh ../libtool --mode=link gcc -g -O2 -o libxfcegui4.la -rpath /opt/xfce4/lib -export-dynamic -version-info 2:0:1 -export-symbols-regex "^[^_].*" -L/usr/X11R6/lib -L/usr/X11R6/lib libxfcegui4_la-dialogs.lo (略) libxfcegui4_la-gtkicontheme.lo -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSM -lICE -lX11 -lSM -lICE -lX11 -L/opt/xfce4/lib -lxfce4util -lglib-2.0 によって、 gcc -shared .libs/libxfcegui4_la-dialogs.o (略) .libs/libxfcegui4_la-gtkicontheme.o -L/usr/lib -L/usr/X11R6/lib /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl -lSM -lICE -lX11 -L/opt/xfce4/lib /usr/lib/libxfce4util.so /usr/lib/libglib-2.0.so -Wl,--export-dynamic -Wl,-soname -Wl,libxfcegui4.so.1 -Wl,-version-script -Wl,.libs/libxfcegui4.ver -o .libs/libxfcegui4.so.1.1.0 と、/usr/lib/libxfce4util.soがリンクされます (続く) 125 名前：120(続き) mailto:sage [04/03/04 21:16.net] 対してlibxfce4mcsでは、 /bin/sh ../libtool --mode=link gcc -g -O2 -o libxfce4mcs-manager.la -rpath /opt/xfce4/lib -export-dynamic -version-info 2:0:1 -export-symbols-regex "^[^_].*" -L/usr/X11R6/lib -L/usr/X11R6/lib libxfce4mcs_manager_la-mcs-channel.lo (略) libxfce4mcs_manager_la-mcs-manager.lo -lSM -lICE -lX11 -lSM -lICE -lX11 -L/opt/xfce4/lib -lxfce4util -lglib-2.0 によって gcc -shared .libs/libxfce4mcs_manager_la-mcs-channel.o (略) .libs/libxfce4mcs_manager_la-mcs-manager.o -Wl,--rpath -Wl,/opt/xfce4/lib -Wl,--rpath -Wl,/opt/xfce4/lib -L/usr/lib -L/usr/X11R6/lib -lSM -lICE -lX11 -L/opt/xfce4/lib /opt/xfce4/lib/libxfce4util.so /usr/lib/libglib-2.0.so -Wl,-soname -Wl,libxfce4mcs-manager.so.1 -Wl,-version-script -Wl,.libs/libxfce4mcs-manager.ver -o .libs/libxfce4mcs-manager.so.1.1.0 と、/opt/xfce4/lib/libxfce4util.soがリンクされます。 この2つは、何がちがってリンクされるlibxfce4util.soが変わるのかがわからないのですが、どこを調べれば いいのでしょうか？ 126 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/03/04 22:03.net] pkg-configか？と脊髄反射してみる 127 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/03/04 22:09.net] >>125 二つのconfigure.acを見比べると、 www.lunar-linux.org/cgi-bin/viewcvs.cgi/*checkout*/xfce4/libxfcegui4/configure.ac?rev=1.45&cvsroot=Xfce&content-type=text/plain では dnl Check for required packages BM_DEPEND([GTK], [gtk+-2.0], [2.0.6]) BM_DEPEND([LIBXFCE4UTIL], [libxfce4util-1.0], [4.1.6]) になっていて、 www.lunar-linux.org/cgi-bin/viewcvs.cgi/*checkout*/xfce4/libxfce4mcs/configure.ac?rev=1.17.2.4&cvsroot=Xfce&content-type=text/plain では dnl Check for dependancies BM_DEPEND([LIBXFCE4UTIL], [libxfce4util-1.0], [4.0.0]) になっているので、違うものがリンクされる可能性はありますが、 それならguiのほうが新しい方を選択しそうですよね。 偉そうに書いておきながら、よく分からんです。 識者の降臨をお待ちします。 128 名前：120 mailto:sage [04/03/04 23:49.net] みなさん、すいません。 わからんわからんといいながら、解決してしまいました。 書き込みで両方のログをコピペしたときに、両方のlibtoolの部分の違いに気づいてしまいました。 「ん? -lhogeの前に-Wl,--export-dynamicがついてるな>libxfcegui4」 で、export-dynamicで調べてみると、 「動的リンクされた実行形式を作る時に, 全てのシンボルを動的シンボル表に追加する.」 とか書いてあって、よくわからなかったのですが、なんかリンクを動的にやろうとするから /usr/lib/libxfce4util.soの方を見てしまうのかな?と思ったので、-lxfce4util の前に export-dynamicがこないようにすればいいのかと思って-lxfce4utlがexport-dynamicの後に くるようにしたところ、libxfcegui4.soが/opt/xfce4/lib/libxfce4utl.soにリンクするようになりました。 #実際にやったのは、libxfce4gui4/Makefile.inでのリンカの呼出で、gtkのリンクオプションと #libxfce4utilのリンクオプションの順番を交換した #(-Wl.-export-dynamicは"pkg-config gtk+-2.0 --libs"に含まれているため) ということで、libtoolというより、なんかリンカの問題点だったような気もしてきた。 みなさん、お騒がせしました。 129 名前：神の愛の証言者 ◆IHSXPiND6Q mailto:sage [04/07/05 17:56.net] 4ヶ月立ってもスレがDAT逝きしないとは素敵なスレですね。 さて、automake で bison をいじろうとしています。 確かに Makefile.am に parser_SOURCES = parser.y lexer.l と書くと bison/flex がたちあがって parser.c / lexer.c を吐き出し、 さらにこいつらが実行可能形式にコンパイルされるわけですが、 make clean で parser.c / lexer.c が消えない。 おまけに AM_YFLAGS = -dで parser.y から parser.h を生成しても、 その依存関係が Makefile に記述されていません。 1. make clean, make dist とかで parser.c, lexer.c を消す方法 2. parser.h と parser.y の依存関係を Makefile に記述させる方法 を教えて下さい。 130 名前：神の愛の証言者 ◆IHSXPiND6Q mailto:sage [04/07/05 18:30.net] >>129 自己レス parser.c とか lexer.c を消したいなら make maintainer-clean を使うとよい。 ただし、なんで clean と maintainer-clean が別なのかその理由が分からない。 automake が吐き出す Makefile はちゃんと parser.y と parser.h の依存関係を 理解している。ただし、互換性維持のために parser.ht という新しいヘッダファイルを一旦生成し、 元からある parser.h と比較して、 内　容　が　本　当　に　違　っ　て　い　た　場　合　に　限　り parser.h を上書きする。だから、単に parser.y のタイムスタンプを新しくしても parser.h は更新されない。 131 名前：名無しさん＠お腹いっぱい。 [04/08/03 03:28.net] なんでこんなにたくさんバージョンがあるんだろう。 使いづらくてかなわん。 132 名前：保守 mailto:sage [04/08/08 14:36.net] >>131 ヴァージョンがたくさんあるのは、上の方で言われている通り、 後方互換性(backward compatibility)が維持できていないからですね。 使いにくいのは>>81さんの通りかと;-) 133 名前：名無しさん＠お腹いっぱい。 [04/08/15 18:24.net] 教えてください。以下のようなソースがあるとして、 ・main.cc 　　#ifdef HAVE_DIRECTX 　　#include "directx_test.h" 　　#else 　　#include "opengl_test.h" 　　#endif ・directx_test.h directx_test.cc ・opengl_test.h opengl_test.cc ./configure --enable-openglした場合に 必要なソースだけ選択的にcompile, linkさせるって どのようにMakefile.amを書けば良いでしょうか？ 状況に応じて依存関係が変化してくれると助かるのですが ・directx使用時 main_SOURCES = main.cc directx_test.h directx_test.cc ・opengl使用時 main_SOURCES = main.cc opengl_test.h opengl_test.cc ほかに、directx用とopengl用にdirectoryとMakefile.amを二つ用意するのも手だと思いますが、 top directoryで./configure, makeした場合、linuxでcompileできない directxに関係するソースを無視させるにはどうやったら良いでしょうか？ 134 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/16 08:01.net] >>133 --enable-openglのときにHAVE_DIRECTXがundefされるんなら bin_PROGRAMS = hoge hoge_SOURCES = main.cc if HAVE_DIRECTX hoge_SOURCES += directx_test.h directx_test.cc else hoge_SOURCES += opengl_test.h opengl_test.cc endif でできんかな？ info automakeのBuilding a programのConditional compilations あたり。 135 名前：133 mailto:sage [04/08/16 13:35.net] >>134 キモはAM_CONDITIONALとifの組み合わせだったのですね。 やりたいことが実現できてすっきりです。ありがとうございます。 136 名前：名無しさん＠お腹いっぱい。 [04/10/08 13:12:44.net] あるプログラムは C、あるプログラムは シェルスクリプト、あるプログラムは Perl を使って書かれた パッケージを autoconf, automake でインスコさせたい時、 シェルスクリプトとか Perl に関する指示はどう出せばいいんですか? 137 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/08 13:26:04.net] Makefile.amに bin_SCRIPTS = fugafufu.pl とか？ 138 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/06 17:50:44.net] 嘔吐makeなんか嫌いだ〜 手書きで書けYO!! 139 名前：名無しさん＠お腹いっぱい。 [04/12/14 03:37:20.net] AC_CHECK_SIZEOF(wchar_t) の結果を Makefile(.am) 内で知りたいのだが、 何かうまい方法はないもんですかね・・・。 （wchar_t のサイズが Linux と Cygwin で違うから、コンパイルするファイルを 振り分けたい、というのが動機です） 140 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/12/14 04:11:52.net] まだあったのか、このスレ。 >>138 make組ハケーン >>139 AM_CONDITIONAL 141 名前：139 [04/12/15 00:03:31.net] >>140 レスどうもでつ。 結局 AC_CANONICAL_HOST で逃げることにしますた。 142 名前：名無しさん＠お腹いっぱい。 mailto:age [2005/05/05(木) 14:20:02 .net] 143 名前：名無しさん＠お腹いっぱい。 [2005/05/07(土) 09:54:27 .net] -lhogeでstatic-linkさせる方法を教えて下さい。 144 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/07(土) 12:38:59 .net] >>143 自作のライブラリなら， hoge_LDFLAGS = -static をMakefile.amに追加するのかな？ make時なら，./configure --helpして それなりのオプションがあれば可能だと思う． 145 名前：名無しさん＠お腹いっぱい。 [2005/05/07(土) 23:00:52 .net] ありがとうございました 146 名前：名無しさん＠お腹いっぱい。 [2005/05/08(日) 14:02:17 .net] 共有ライブラリのバージョンが違っても動くプログラムを作る方法を教えて下さい 147 名前：名無しさん＠お腹いっぱい。 [2005/05/09(月) 17:10:53 .net] libtoolで困ってます。libtool 1.5->1.5.8でなにか大きな変更があったんでしょうか？ (FreeBSDスレで質問したのですが、だれも答えてくれなかったのでこちらへ来ました。 FreeBSD特有の問題でもなさそうですし…) (1) FreeBSD-5.2.1, autoconf-2.57, automake-1.7.5_1, libtool-1.5 で開発をしていたのですが、FreeBSD-5.3に移行しようと思い、 (2) FreeBSD-5.3, autoconf-2.57, automake-1.7.5_1, libtool-1.5.8 で環境を整え開発中のソースをビルドしたのですが、 libtoolが作ってくれるはずの共有ライブラリがビルドされません。 ＃libtoolのバージョンのみ変わった。 > cp /usr/local/share/aclocal/libtool15.m4 acinclude.m4 > libtoolize15 --force --copy > aclocal > autoheader > automake -a -c --gnu --add-missing --force-missing んで、 > ./configure > make これで環境(1)では共有ライブラリができるのですが、環境(2)ではできなくなってしまいました。 (1)と(2)ではlibtoolizeがコピーするファイルが主に違っているので、libtoolizeが原因かと思い、 環境(2)でソースから libtool-1.5 をインストールしてやると共有ライブラリはビルドできました。 libtool-1.5.16もソースからインストールして同様にビルドすると、今度は共有ライブラリはできませんでした。 configure.ac 内では、AC_PROG_LIBTOOL を指定 Makefile.am では、 lib_LTLIBRARIES = libhoge.la としています。 libtool-1.5 から libtool-1.5.8 の間にautoconf等の指定の仕方が変わったのでしょうか？ ＃なにか指定し忘れてるのだろうか,,, 148 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/09(月) 18:05:40 .net] >>147 libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか？ 確か最近のAutotoolsは同じprefixにしないと問題があるとMLに流れていたと思います。 # ググってもCygwin関係の話しか出てこない (^^; 確認してみてください。 また、(2)の最初の環境ではそのような問題は無いと思うので、 一度、buildディレクトリをクリーンにして試してみてください。 make maintainer-clean だったっけ？ その後で、autoreconf -f -i -Wall してみてください。 autoconfとautomakeのバージョンによっては、 autoreconfがうまく動作しないかもしれないので、 そのときはちょっと困ります。 config.logあたりに何故できないかの情報があるかもしれないので、 ながめてみてください。 149 名前：147 mailto:sage [2005/05/10(火) 00:08:44 .net] >>148 ご丁寧にありがとうございます。 > libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか？ これは同じです。すべて prefix は /usr/local としています。 > 一度、buildディレクトリをクリーンにして試してみてください。 > make maintainer-clean だったっけ？ > その後で、autoreconf -f -i -Wall > してみてください。 これもやってみたのですが、状況は変わりませんでした。 ちなみに autoreconf をすると以下の Warning が出ました。 > autoreconf -f -i -Wall configure.ac:34: warning: The macro `AC_TRY_LINK' is obsolete. You should run autoupdate. 　　　　: これらのWarningは configure.ac の AC_PROG_LIBTOOL でインクルード？される libtool15.m4 (acinclude.m4 としてconfigure.ac と同じディレクトリにおいてある。) で出ている模様。 でも、Warning だけなのでいけそうな気もするんですが…。 > config.logあたりに何故できないかの情報があるかもしれないので、 > ながめてみてください。 これもみてみたのですが、shared lib 関連はとくに問題なさそうでした。 とりあえず、libtool-1.5 を使っていようと思います。ありがとうございました。 150 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/10(火) 00:16:22 .net] >>149 あまりお役に立てなかったようで、、、 後は、ソースからビルドされたようなので、 libtoolのmakeに失敗している可能性もあるので、 libtoolをmakeしたディレクトリでmake checkして、 問題が無いか確認するぐらいかな？ 151 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/12(木) 00:45:45 .net] ↓の書き込みも漏れだったりするけど、多分これだと思う。 540 名前：名無しさん＠お腹いっぱい。：05/02/05 01:29:46 >539 そもそも X 自体入れてないんでどうなんか知らんが。 作らないんじゃなくて、作るけどわざわざ入れないようだ。 devel/libtool15 にわざわざ .la をインストールしないようパッチがされてる。 参考: ttp://www.freebsd.org/cgi/query-pr.cgi?pr=76363 とりあえず x11/libxfce4/Makefile で -USE_LIBTOOL_VER=15 +USE_INC_LIBTOOL_VER=15 してやれば .la も入るみたいだけど？ 152 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/12(木) 00:46:58 .net] >151 あー、ごめん早とちりしたかも。 153 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/05/25(水) 21:12:32 .net] www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/dl/autotools.pdf 英語だけどわかりやすい 154 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/06/23(木) 12:44:19 .net] autopoint で i18n 化した場合って、GPL 互換のライセンスにしないと駄目なの？ intl/ の下に出来るファイルは全部 GPL だよね？ ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。 155 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/06/23(木) 18:12:59 .net] >>154 info gettextのDiscussionsの * Dependencies over the GPL or LGPL に[The simplest answer is "normally not".]と書かれている。 一応、読んでみてね。 156 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/06/23(木) 18:32:19 .net] >>155 thx。でも英語が分からん…＿|￣|○ 一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも 配布できるという解釈で OK? 157 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/06/23(木) 20:25:51 .net] >>156 日本語訳 ring.atr.jp/archives/doc/gnu-info-j/gettext/gettext-ja.html#SEC59 やっぱりよくわからんけど、そんな感じだと思うけどね。 158 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/06/24(金) 01:56:18 .net] よくわからんが、intlの下ってlibintlに入るものと同じなんでしょ? 削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの? 159 名前：名無しさん＠お腹いっぱい。 [2005/10/18(火) 13:52:00 .net] こんにちは。 以下のようなツリーで programA を静的にビルドすると、 　In function '(programAの関数)': 　undefined reference to 'subB1の関数' と表示されてエラーになります。ディレクトリには subB1.o subB2.o subA1.o subA2.o programA.o ができてるのですが、 あれこれ調べても原因がわかりません。ヒントでよいですので助言を お願いします。 / ┃ ┣[programB]━┳━[subB1] subB1.c ┃　　　　　　　　 ┃ ┃　　　　　　　　 ┃ ┃　　　　　　　　 ┗━[subB2] subB2.c ┃ ┗[programA]━┳━Makefile.am, configure.in 　　　　　　　　　　┃ 　　　　　　　　　　┣━[subA1] subA1.c 　　　　　　　　　　┃ 　　　　　　　　　　┣━[subA2] subA2.c 　　　　　　　　　　┃ 　　　　　　　　　　┣━[src] programA.c 　　　　　　　　　　┃ 　　　　　　　　　　┗ subB1.o subB2.o subA1.o subA2.o programA.o 160 名前：名無しさん＠お腹いっぱい。 [2005/10/18(火) 13:56:04 .net] ツリーのみ： / ┃ ┣[programB]━┳━[subB1] subB1.c ┃　　　　　　　　 ┃ ┃　　　　　　　　 ┃ ┃　　　　　　　　 ┗━[subB2] subB2.c ┃ ┗[programA]━┳━Makefile.am, configure.in 　　　　　　　　　　┃ 　　　　　　　　　　┣━[subA1] subA1.c 　　　　　　　　　　┃ 　　　　　　　　　　┣━[subA2] subA2.c 　　　　　　　　　　┃ 　　　　　　　　　　┣━[src] programA.c 　　　　　　　　　　┃ 　　　　　　　　　　┗ subB1.o subB2.o subA1.o subA2.o programA.o 161 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/18(火) 15:51:25 .net] >>159 subB1.oをリンクし忘れてるとか リンクの際に引きわたす.oの順番を変えてみるとか 162 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/18(火) 16:31:26 .net] Makefile.am での”xxx_LIBRARIES =, xxx_SOURCES =”や configure.in での”AC_CONFIG_FILES()”以外に、 リンク先の指定方法があるのでしょうか？？ なんとなく、各 Makefile.am でリンク先の指定とか できそうに思うのですが、調べても判りません orz。 163 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/20(木) 22:59:06 .net] >>159 なんでそんな不思議な事を… programBのツリー内でlibprogramB.aでも作ればいいんじゃない 164 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/21(金) 20:05:57 .net] programA と programB はもともと別の自作ツールで、programB の 一部のソースを programA に流用したもので、Makefile を直接 編集したときはちゃんとコンパイルできるのに、下記のような Makefile.am configure.in を書いて autoconf automake すると >>159 のようなエラーが表示されます。なにが悪いのやら… ■ Makefile.am bin_PROGRAMS = pgA pgA_SOURCES = \ ../programB/subB1/subB1.c \ ../programB/subB2/subB2.c \ subA1/subA1.c \ subA2/subA2.c \ src/programA.cc SUBDIRS = ../programB/subB1 ../program/subB2 subA1 subA2 src 165 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/21(金) 20:07:30 .net] ■ configure.in AC_PREREQ(2.59) AC_INIT(pgA, 0.1.0, BUG-REPORT-ADDRESS) AC_CONFIG_SRCDIR([src/programA.c]) AC_CONFIG_HEADER([config.h]) AM_INIT_AUTOMAKE(pgA, 0.1.0) AM_PROG_LIBTOOL AC_PROG_INSTALL AC_PROG_LN_S AC_PROG_MAKE_SET AC_PROG_RANLIB AC_PROG_CXX AC_PROG_CC AC_PROG_CPP AC_HEADER_DIRENT AC_HEADER_STDC AC_CHECK_HEADERS([stdlib.h string.h]) AC_C_CONST AC_TYPE_SIZE_T AC_FUNC_MALLOC AC_CHECK_FUNCS([memset strchr strstr]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT 166 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/22(土) 09:40:24 .net] >>164 共通部分はライブラリにしてしまうのがいいと思うのだが、 後、SOURCESなどでは相対パスではなく、$(top_srcdir) などを利用するのが、最近の流儀です。 # configureを任意のディレクトリで実行可能にするため。 また、SUBDIRSがサブディレクトリではないのも問題になるかも しれません。 パッケージ構成を再検討したほうがいいと言うのに私も賛成。 167 名前：名無しさん＠お腹いっぱい。 mailto:sage [2005/10/22(土) 20:26:11 .net] 自己解決しました。 *.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで なかったのが原因のようですた。これで make が通るようになり pgA が 出来上がったのですが、いまいち腑に落ちないです。なんかちょっと 書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。 まあ、自分が悪いのですが。　お答えいただいた皆さんありがとう ございました。 168 名前：名無しさん＠お腹いっぱい。 [2006/03/27(月) 13:22:52 .net] www.ossp.org/pkg/tool/lmtp2nntp/ これなんですけど、LIBS って環境変数を設定してたら、configure に失敗します。 メインの configure で LIBS を自分用にライブラリ追加して設定してるんだけど、 サブの configure にLIBSが環境変数だから引き継がれて悪影響が出てる。 これって、どれ？ 1. LIBS を環境変数として指定するのは間違い 2. メインの configure.ac の書き方がまずい 3. autoconf なんてそんなもの 169 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/27(月) 21:49:45 .net] >>168 LIBSをunsetしてから LIBS=hoge ./conifgure とすると、サブのconfigureに引き継がれないという噂が 利用できるかもしれないが、そうでなければ、 > 1. LIBS を環境変数として指定するのは間違い かな？ > 3. autoconf なんてそんなもの これの気もするが、、、 170 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/28(火) 17:34:44 .net] > LIBS=hoge ./conifgure だめみたい。 うーん、configure.ac で LIBS="$LIBS_EXTRA $LIBS" するのを止めて、Makefile.in で、 LIBS = @LIBS_EXTRA@ @LIBS@ しないとだめなのかなぁ。 ぶー、ぶさいく。 171 名前：名無しさん＠お腹いっぱい。 [2006/03/32(土) 13:15:03 .net] ./configure LIBS=hoge 172 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/32(土) 15:03:08 .net] ちらしの裏に書いて置くべきことなは、 承知のうえで、あえて、誰かに聞いてもらいたい。 Autoconf,Automake,libtoolのおかげで、コンパイル、インストール は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ って思うときに、なんかわけわからなくて。 makefileを自作してたりする。んでそれが面倒なんでソース弄るのも おっくうになってたり。 みんなはどうしてるの？ 173 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/32(土) 15:15:07 .net] 自分で書くCソースはそもそもそんなに複雑じゃないので、 autoconfを使わなくてもMakefileはOSに依存せず、 異なるOS間でも共通(同一)になることが多い。 なので、Makefileを自分で直接書いてる。 もしくは、もっと簡単なソースだとMakefileすら要らず、 makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。 174 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/03/32(土) 17:58:32 .net] >>172 使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので それを自動化したprepare_projectなるスクリプトを書いて使ってる 175 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/04/02(日) 06:43:54 .net] autoconfは便利だしとっつきやすいが、 automakeまで手を伸ばすのはちと面倒なんだよな。 どうせ最初から使う必要なんてないんだから、 必要を感じてきたらそのとき導入すればいいよ。 >> prepare_projectなるスクリプト MS的にいうとautotools_wizardだね 176 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/04/02(日) 12:22:16 .net] >>171 なるほど。これいけるね。 177 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/04/03(月) 03:18:57 .net] >>175 autoconf単独よりautomakeとセットで使う方が断然らくちんだべや 178 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/04/07(金) 23:19:18 .net] NFS上でaclocal等を実行すると、perlがflock使っているところで 止まるんだけど、これってperlを-Ud_flock付きでコンパイルする 以外に方法はないのでしょうか？ (aclocalは1.9.6) 179 名前：名無しさん＠お腹いっぱい。 [2006/06/27(火) 20:01:13 .net] 型のサイズが違ったらエラーを出すようにしたいのですけど、 どうしたらいいでしょうか。 configure.inに AC_CHECK_SIZEOF(int) AM_CONDITIONAL(CHECK_INT, test "$SIZEOF_INT" = 4) Makefile.amに if !CHECK_INT endif と書いてみたのですけど、if〜endifの間の書き方が分かりません。 よろしくお願いします。 180 名前：名無しさん＠お腹いっぱい。 [2006/07/18(火) 14:34:27 .net] >>179 configureの時点で止めてしまうって話でいいのなら、下の感じだとおもう。試してはいないけど。 AC_CHECK_SIZEOF(int) if test $SIZEOF_INT != 4; then AC_MSG_FAILURE([aaaa]) fi 181 名前：179 mailto:sage [2006/07/18(火) 21:03:26 .net] >>180 あれからconfigure.inではなくてconfigure.acを使うようにしたのですが、 configure.acの中からではSIZEOF_INTが見えないようです。 生成されたconfigureを見てみると #define SIZEOF_INT $ac_cv_sizeof_int という行がありましたので、 AC_CHECK_SIZEOF(int) if test x$ac_cv_sizeof_int != x"4"; then AC_MSG_FAILURE([int must be 4 bytes.]) fi としてみたらうまくいきました。ありがとうございました。 182 名前：名無しさん＠お腹いっぱい。 [2006/07/20(木) 20:39:59 .net] autoconf-archive autoconf-archive.cryp.to/macros-by-category.html を見ていると、マクロの先頭が、AC,ACX,AXなどいくつかありますが、 それぞれどのような違いがあってつけられているのでしょうか。 183 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/10/16(月) 21:53:55 .net] automake-1.10が出たので、autoconf-2.60とともに試しにいれてみた。 ついでにm4-1.4.6にしてみた。古いautoconf関係との解離は大きくなった感じ。 あと、autoconf-2.60のmake checkでエラーになるのだが、 これは、m4-1.4.6のせいで、autoconf-2.60aにするといいらしい。 とりあえず、こんな状況。 184 名前：名無しさん＠お腹いっぱい。 [2006/11/24(金) 03:55:10 .net] --with-foo=XXXXの値をMailfileのDEFS変数に反映させてgccのプリプロセッサに反映させたいのですがうまくいきません。 やり方教えて頂けないでしょうか。 AC_ARG_WITH([foo], [ --with-foo (default is /etc/foo)], def_foo=$withval, def_foo=/var/foo) AC_DEFINE([HAVE_FOO, [def_foo]) としてもMakefileでは gcc -DHAVE_FOO=def_foo となってしまいます、、 185 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/11/24(金) 06:20:37 .net] AC_DEFINE_UNQUOTED 186 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/11/24(金) 06:35:43 .net] 今も聞こえる オウトマケの唄 187 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/11/25(土) 03:01:50 .net] >>185 変更したら解決できました。 ありがとうございます。 188 名前：名無しさん＠お腹いっぱい。 [2006/12/03(日) 05:15:59 .net] AC_CHECK_LIBに/usr/local/libなどのディレクトリも見てもらうようにするには どうしたらいいんでしょうか？ 189 名前：名無しさん＠お腹いっぱい。 [2006/12/08(金) 09:17:54 .net] そもそも、 AC_CHECK_HEADERSがヘッダを探すサーチパス、 AC_CHECK_LIBがライブラリを探すサーチパス、 は、 どこで定義されていて、 どうやったらそこに任意のディレクトリを追加できるのでしょう？ ドキュメントには記述が発見できず... 190 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/08(金) 14:19:02 .net] apacheやqmailみたいに１パッケージに複数のアプリケーションが含まれているようなソースツリーの場合にいい感じにconfigureを量産してくれるようなautotoolsが欲しい。 191 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/08(金) 20:42:36 .net] /usr/share/autoconf とかその辺にあるよ 192 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/09(土) 22:48:56 .net] >>191 ありがとうございます。 /usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。 /usr/share を変更できない権限で configure 実行時にサーチパスを追加 する方法を探しています。 環境変数INCLUDEにセットしてみたり、 ./configure INCLUDE=hoge とかやってみているのですが、うまくいかずです。 193 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/13(水) 15:01:54 .net] ./src 　main.c 　./others 　　hoo.h という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am はどのように書けばいいのでしょうか？ 194 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/13(水) 15:03:01 .net] すいません書き忘れです。 ./others 　hoo.h 　hoo.c という感じです 195 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/14(木) 04:27:56 .net] >>192 環境変数で解決しました。 AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、 AC_CHECK_LIB は LIBS=-L<lib_dir> で設定したディレクトリを探してくれるようです。 196 名前：手元にある本から・・・ [2006/12/16(土) 18:51:20 .net] >193 GNU Autoconf/Automake/Libtool ttp://www.amazon.co.jp/Autoconf-Automake-Libtool-Gary-Vaughan/dp/4274064115/ P48 6.5:よくある質問　から引用 ライブラリのソースが複数のサブディレクトリにあるとき、どうmakeしたらよいでしょうか？ ライブラリではほとんどの場合、libtoolコンビニエンスライブラリを使うことで簡単に解決できます。 しかし、プログラムについては簡単な解決策がなく、パッケージの構造の変更を選ぶ人が少なく有りません。 Automakeの次期メジャーリリースでは、この問題に進展があるはずです。 最新verならできるのかな？この本が翻訳された段階(平成13年)ではまだ無理っぽいみたいだし 197 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/16(土) 19:59:25 .net] >>196 ありがとうございます どうにも良く分からないので ./src 　main.c 　./others 　　hoo.h 　　hoo.cpp を、libothers.aとライブラリにして、./srcでリンクさせてます。（リンクが成功しないんですがこれは別問題かと） うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか 198 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/16(土) 20:55:20 .net] >>196,197 今試したら少なくともautomake-1.9.5だと うまくサブディレクトリを扱えるみたい 199 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/17(日) 04:04:49 .net] 具体的な書き方が分からないのですが、教えていただけませんか？ 200 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/12/17(日) 09:22:03 .net] >>199 とりあえず、、、試してみた。 topdirのMakefile.am (プログラム名はhooと仮定) SUBDIRS = others bin_PROGRAMS = foo foo_SOURCES = main.c foo_LDDADD = $(top_builddir)/othes/libhoo.la foo_CFLAGS = -I$(top_srcdir)/others foo_LDFLAGS = -L$(top_builddir)/others -lhoo othersのMakefile.am lib_LTLIBRARIES = libhoo.la libhoo_la_SOURCES = hoo.c hoo.h configure.ac AC_PREREQ(2.61) AC_INIT([foo], [0.0.0], [nanasi@example.com]) AC_CONFIG_SRCDIR([main.c]) AC_CONFIG_HEADER([config.h]) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_PROG_LIBTOOL AC_CONFIG_FILES([Makefile others/Makefile]) AC_OUTPUT 201 名前：198 mailto:sage [2006/12/17(日) 18:48:32 .net] >>199 具体的もなにもmain.cのあるディレクトリのMakefile.amで hoge_SOURCES=main.c others/hoo.h others/hoo.cpp するだけだよ othersにあるファイルも同じように扱えるようになったみたいなので わざわざライブラリにまとめる必要はない

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef