0001名無しさん＠お腹いっぱい。
NGNG関連サイトは>>2
探検
Autoconf,Automakeについて
関連サイトは>>2
0101名無しさん＠お腹いっぱい。
NGNGああ、Makefile.amの間違いだよな。
0102名無しさん＠お腹いっぱい。
NGNGありがとうございます。
ところでprefixを/usrにするとどういうデメリットがあるのでしょうか？
0103名無しさん＠お腹いっぱい。
NGNGごめんなさい。その通りMakefile.amの間違いです。
0104名無しさん＠お腹いっぱい。
NGNG/usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと
ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。
/usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。
Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い
(衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って
そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。
0105名無しさん＠お腹いっぱい。
NGNGシステム上重要というだけでなく、そのOSを使っている人の間で構成が
一致しているからでもある。
Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ
うのも納得できる。
>>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。
0106名無しさん＠お腹いっぱい。
NGNGいう概念が無いからなぁ。「無けりゃインストールしろ」「インストール
したらそれもbase systemの一部だ」みたいなノリなんだろうね。
0107ヽ(´ー`)ノ
NGNGLinux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。
最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。
特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。
> Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
これは、もはや昔話だよもん。
0108名無しさん＠お腹いっぱい。
NGNG0109名無しさん＠お腹いっぱい。
NGNGmaximum length of command line argumentsとか言ってCPU食うのを
やめさせたいんですけど。そういうACマクロはないんでしょうか？
0110名無しさん＠お腹いっぱい。
NGNG「勝手」にチェックする m4 なんてない。
configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。
気に入らなきゃチェックしてるところを外せ。
# それでまともにコンパイルできるとは思えんが。
0111名無しさん＠お腹いっぱい。
NGNGほとんどのパッケージには不要なはずのチェックが盛りだくさんに
はいるわけです。
とりあえず全部チェックしておけばどんな場合にも対応できるってこと
なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、
そういうマクロあります？って話です。
libtool.m4が洗練されてないと言えばそれまでですがね。
0112名無しさん＠お腹いっぱい。
NGNG0113名無しさん＠お腹いっぱい。
NGNGAC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、
自分でlibtool.m4を書き換えちゃえば？
うまく動く保証は無いし、libtool使う意味も減ると思うけど。
移植性考えないんならlibtool使わなくてもいいんじゃないかな？
0114名無しさん＠お腹いっぱい。
NGNG全項目を保証する気なんてないし、不可能ですから、どこまでチェック
するかの問題ですね。AutoconfにしてもLibtoolにしても。
ですから「移植性考えないならlibtool使わなくていい」なんてのは極論です。
このチェックに関して言えば、ソースのビルド中にコマンドラインの
最大長を超えるコマンドは分割実行するようになっているみたいですが、
環境によっては数分以上かかるようなチェックをするより、4096とか
小さい値を決めうちしたほうがいいですね。実際そうしましたが。
コマンドに4096バイトも入らないプラットフォームは問題外ですから
無視でよいです。デフォルトがチェックになってるのは仕方ないですが。
0115名無しさん＠お腹いっぱい。
NGNG0116名無しさん＠お腹いっぱい。
NGNGプラットホームは俺の中で問題外なんだけどなｗ
何のために libtool 使ってんのか分からんよ。
0117名無しさん＠お腹いっぱい。
NGNGconfigure時の話なら、config.siteじゃできんかな？
lt_cv_sys_max_cmd_lenがキャッシュにあれば良さそうなんで、
test "$lt_cv_sys_max_cmd_len" = NONE && lt_cv_sys_max_cmd_len=4096
みたいな内容を書いとけばいいかもね。
# 試してないんで違うかもしれん。
# 今、バージョンの不一致でautotoolsがうまく動かない(泣)
0118名無しさん＠お腹いっぱい。
NGNG$ ./configure --lt_cv_sys_max_cmd_len=4096
でいけるかもしれんような気がした。
しかし、試せない。。。
0119名無しさん＠お腹いっぱい。
NGNG>>118
> $ ./configure --lt_cv_sys_max_cmd_len=4096
ではなく、
$ ./configure lt_cv_sys_max_cmd_len=4096
だね。
0120名無しさん＠お腹いっぱい。
NGNG0121名無しさん＠お腹いっぱい。
NGNG問題があれば誘導されるでしょ。
0122名無しさん＠お腹いっぱい。
NGNGわけですが、これらを動的にチェックするんじゃなくて静的にデータ
ベースのようなもので持たせることはできないですかね。とはいっても
何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう
わけでなかなか難しいんだろうけど。
0123名無しさん＠お腹いっぱい。
NGNGそのためにはconfig.siteを使えばいいと思うんだけど。
0124120
NGNGでは、御言葉に甘えて。
ちょっとした理由で、安定版の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がリンクされます (続く)
0125120(続き)
NGNG/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が変わるのかがわからないのですが、どこを調べれば
いいのでしょうか？
0126名無しさん＠お腹いっぱい。
NGNG0127名無しさん＠お腹いっぱい。
NGNG二つのconfigure.acを見比べると、
http://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])
になっていて、
http://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のほうが新しい方を選択しそうですよね。
偉そうに書いておきながら、よく分からんです。
識者の降臨をお待ちします。
0128120
NGNGわからんわからんといいながら、解決してしまいました。
書き込みで両方のログをコピペしたときに、両方の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というより、なんかリンカの問題点だったような気もしてきた。
みなさん、お騒がせしました。
0129神の愛の証言者 ◆IHSXPiND6Q
NGNGさて、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 に記述させる方法
を教えて下さい。
0130神の愛の証言者 ◆IHSXPiND6Q
NGNG自己レス
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 は更新されない。
0131名無しさん＠お腹いっぱい。
NGNG使いづらくてかなわん。
0132保守
NGNGヴァージョンがたくさんあるのは、上の方で言われている通り、
後方互換性(backward compatibility)が維持できていないからですね。
使いにくいのは>>81さんの通りかと;-)
0133名無しさん＠お腹いっぱい。
NGNG・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に関係するソースを無視させるにはどうやったら良いでしょうか？
0134名無しさん＠お腹いっぱい。
NGNG--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
あたり。
0135133
NGNGキモはAM_CONDITIONALとifの組み合わせだったのですね。
やりたいことが実現できてすっきりです。ありがとうございます。
0136名無しさん＠お腹いっぱい。
NGNGパッケージを autoconf, automake でインスコさせたい時、
シェルスクリプトとか Perl に関する指示はどう出せばいいんですか?
0137名無しさん＠お腹いっぱい。
NGNGbin_SCRIPTS = fugafufu.pl
とか？
0138名無しさん＠お腹いっぱい。
NGNG手書きで書けYO!!
0139名無しさん＠お腹いっぱい。
NGNG何かうまい方法はないもんですかね・・・。
（wchar_t のサイズが Linux と Cygwin で違うから、コンパイルするファイルを
振り分けたい、というのが動機です）
0140名無しさん＠お腹いっぱい。
NGNG>>138
make組ハケーン
>>139
AM_CONDITIONAL
0141139
NGNGレスどうもでつ。
結局 AC_CANONICAL_HOST で逃げることにしますた。
0142名無しさん＠お腹いっぱい。
2005/05/05(木) 14:20:020143名無しさん＠お腹いっぱい。
2005/05/07(土) 09:54:270144名無しさん＠お腹いっぱい。
2005/05/07(土) 12:38:59自作のライブラリなら，
hoge_LDFLAGS = -static
をMakefile.amに追加するのかな？
make時なら，./configure --helpして
それなりのオプションがあれば可能だと思う．
0145名無しさん＠お腹いっぱい。
2005/05/07(土) 23:00:520146名無しさん＠お腹いっぱい。
2005/05/08(日) 14:02:170147名無しさん＠お腹いっぱい。
2005/05/09(月) 17:10:53(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等の指定の仕方が変わったのでしょうか？
＃なにか指定し忘れてるのだろうか,,,
0148名無しさん＠お腹いっぱい。
2005/05/09(月) 18:05:40libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか？
確か最近のAutotoolsは同じprefixにしないと問題があるとMLに流れていたと思います。
# ググってもCygwin関係の話しか出てこない (^^;
確認してみてください。
また、(2)の最初の環境ではそのような問題は無いと思うので、
一度、buildディレクトリをクリーンにして試してみてください。
make maintainer-clean だったっけ？
その後で、autoreconf -f -i -Wall
してみてください。
autoconfとautomakeのバージョンによっては、
autoreconfがうまく動作しないかもしれないので、
そのときはちょっと困ります。
config.logあたりに何故できないかの情報があるかもしれないので、
ながめてみてください。
0149147
2005/05/10(火) 00:08:44ご丁寧にありがとうございます。
> 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 を使っていようと思います。ありがとうございました。
0150名無しさん＠お腹いっぱい。
2005/05/10(火) 00:16:22あまりお役に立てなかったようで、、、
後は、ソースからビルドされたようなので、
libtoolのmakeに失敗している可能性もあるので、
libtoolをmakeしたディレクトリでmake checkして、
問題が無いか確認するぐらいかな？
0151名無しさん＠お腹いっぱい。
2005/05/12(木) 00:45:45540 名前：名無しさん＠お腹いっぱい。：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 も入るみたいだけど？
0152名無しさん＠お腹いっぱい。
2005/05/12(木) 00:46:58あー、ごめん早とちりしたかも。
0153名無しさん＠お腹いっぱい。
2005/05/25(水) 21:12:32英語だけどわかりやすい
0154名無しさん＠お腹いっぱい。
2005/06/23(木) 12:44:19intl/ の下に出来るファイルは全部 GPL だよね？
ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。
0155名無しさん＠お腹いっぱい。
2005/06/23(木) 18:12:59info gettextのDiscussionsの
* Dependencies over the GPL or LGPL
に[The simplest answer is "normally not".]と書かれている。
一応、読んでみてね。
0156名無しさん＠お腹いっぱい。
2005/06/23(木) 18:32:19thx。でも英語が分からん…＿|￣|○
一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも
配布できるという解釈で OK?
0157名無しさん＠お腹いっぱい。
2005/06/23(木) 20:25:51日本語訳
http://ring.atr.jp/archives/doc/gnu-info-j/gettext/gettext-ja.html#SEC59
やっぱりよくわからんけど、そんな感じだと思うけどね。
0158名無しさん＠お腹いっぱい。
2005/06/24(金) 01:56:18削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの?
0159名無しさん＠お腹いっぱい。
2005/10/18(火) 13:52:00以下のようなツリーで 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
0160名無しさん＠お腹いっぱい。
2005/10/18(火) 13:56:04/
┃
┣[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
0161名無しさん＠お腹いっぱい。
2005/10/18(火) 15:51:25subB1.oをリンクし忘れてるとか
リンクの際に引きわたす.oの順番を変えてみるとか
0162名無しさん＠お腹いっぱい。
2005/10/18(火) 16:31:26configure.in での”AC_CONFIG_FILES()”以外に、
リンク先の指定方法があるのでしょうか？？
なんとなく、各 Makefile.am でリンク先の指定とか
できそうに思うのですが、調べても判りません orz。
0163名無しさん＠お腹いっぱい。
2005/10/20(木) 22:59:06なんでそんな不思議な事を…
programBのツリー内でlibprogramB.aでも作ればいいんじゃない
0164名無しさん＠お腹いっぱい。
2005/10/21(金) 20:05:57一部のソースを 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
0165名無しさん＠お腹いっぱい。
2005/10/21(金) 20:07:30AC_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
0166名無しさん＠お腹いっぱい。
2005/10/22(土) 09:40:24共通部分はライブラリにしてしまうのがいいと思うのだが、
後、SOURCESなどでは相対パスではなく、$(top_srcdir)
などを利用するのが、最近の流儀です。
# configureを任意のディレクトリで実行可能にするため。
また、SUBDIRSがサブディレクトリではないのも問題になるかも
しれません。
パッケージ構成を再検討したほうがいいと言うのに私も賛成。
0167名無しさん＠お腹いっぱい。
2005/10/22(土) 20:26:11*.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで
なかったのが原因のようですた。これで make が通るようになり pgA が
出来上がったのですが、いまいち腑に落ちないです。なんかちょっと
書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。
まあ、自分が悪いのですが。 お答えいただいた皆さんありがとう
ございました。
0168名無しさん＠お腹いっぱい。
2006/03/27(月) 13:22:52これなんですけど、LIBS って環境変数を設定してたら、configure に失敗します。
メインの configure で LIBS を自分用にライブラリ追加して設定してるんだけど、
サブの configure にLIBSが環境変数だから引き継がれて悪影響が出てる。
これって、どれ？
1. LIBS を環境変数として指定するのは間違い
2. メインの configure.ac の書き方がまずい
3. autoconf なんてそんなもの
0169名無しさん＠お腹いっぱい。
2006/03/27(月) 21:49:45LIBSをunsetしてから
LIBS=hoge ./conifgure
とすると、サブのconfigureに引き継がれないという噂が
利用できるかもしれないが、そうでなければ、
> 1. LIBS を環境変数として指定するのは間違い
かな？
> 3. autoconf なんてそんなもの
これの気もするが、、、
0170名無しさん＠お腹いっぱい。
2006/03/28(火) 17:34:44だめみたい。
うーん、configure.ac で
LIBS="$LIBS_EXTRA $LIBS"
するのを止めて、Makefile.in で、
LIBS = @LIBS_EXTRA@ @LIBS@
しないとだめなのかなぁ。
ぶー、ぶさいく。
0171名無しさん＠お腹いっぱい。
2006/03/32(土) 13:15:030172名無しさん＠お腹いっぱい。
2006/03/32(土) 15:03:08承知のうえで、あえて、誰かに聞いてもらいたい。
Autoconf,Automake,libtoolのおかげで、コンパイル、インストール
は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ
って思うときに、なんかわけわからなくて。
makefileを自作してたりする。んでそれが面倒なんでソース弄るのも
おっくうになってたり。
みんなはどうしてるの？
0173名無しさん＠お腹いっぱい。
2006/03/32(土) 15:15:07autoconfを使わなくてもMakefileはOSに依存せず、
異なるOS間でも共通(同一)になることが多い。
なので、Makefileを自分で直接書いてる。
もしくは、もっと簡単なソースだとMakefileすら要らず、
makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。
0174名無しさん＠お腹いっぱい。
2006/03/32(土) 17:58:32使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ
ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん
とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので
それを自動化したprepare_projectなるスクリプトを書いて使ってる
0175名無しさん＠お腹いっぱい。
2006/04/02(日) 06:43:54automakeまで手を伸ばすのはちと面倒なんだよな。
どうせ最初から使う必要なんてないんだから、
必要を感じてきたらそのとき導入すればいいよ。
>> prepare_projectなるスクリプト
MS的にいうとautotools_wizardだね
0176名無しさん＠お腹いっぱい。
2006/04/02(日) 12:22:16なるほど。これいけるね。
0177名無しさん＠お腹いっぱい。
2006/04/03(月) 03:18:57autoconf単独よりautomakeとセットで使う方が断然らくちんだべや
0178名無しさん＠お腹いっぱい。
2006/04/07(金) 23:19:18止まるんだけど、これってperlを-Ud_flock付きでコンパイルする
以外に方法はないのでしょうか？ (aclocalは1.9.6)
0179名無しさん＠お腹いっぱい。
2006/06/27(火) 20:01:13どうしたらいいでしょうか。
configure.inに
AC_CHECK_SIZEOF(int)
AM_CONDITIONAL(CHECK_INT, test "$SIZEOF_INT" = 4)
Makefile.amに
if !CHECK_INT
endif
と書いてみたのですけど、if〜endifの間の書き方が分かりません。
よろしくお願いします。
0180名無しさん＠お腹いっぱい。
2006/07/18(火) 14:34:27configureの時点で止めてしまうって話でいいのなら、下の感じだとおもう。試してはいないけど。
AC_CHECK_SIZEOF(int)
if test $SIZEOF_INT != 4; then
AC_MSG_FAILURE([aaaa])
fi
0181179
2006/07/18(火) 21:03:26あれから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
としてみたらうまくいきました。ありがとうございました。
0182名無しさん＠お腹いっぱい。
2006/07/20(木) 20:39:59http://autoconf-archive.cryp.to/macros-by-category.html
を見ていると、マクロの先頭が、AC,ACX,AXなどいくつかありますが、
それぞれどのような違いがあってつけられているのでしょうか。
0183名無しさん＠お腹いっぱい。
2006/10/16(月) 21:53:55ついでにm4-1.4.6にしてみた。古いautoconf関係との解離は大きくなった感じ。
あと、autoconf-2.60のmake checkでエラーになるのだが、
これは、m4-1.4.6のせいで、autoconf-2.60aにするといいらしい。
とりあえず、こんな状況。
0184名無しさん＠お腹いっぱい。
2006/11/24(金) 03:55:10やり方教えて頂けないでしょうか。
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
となってしまいます、、
0185名無しさん＠お腹いっぱい。
2006/11/24(金) 06:20:370186名無しさん＠お腹いっぱい。
2006/11/24(金) 06:35:430187名無しさん＠お腹いっぱい。
2006/11/25(土) 03:01:50変更したら解決できました。
ありがとうございます。
0188名無しさん＠お腹いっぱい。
2006/12/03(日) 05:15:59どうしたらいいんでしょうか？
0189名無しさん＠お腹いっぱい。
2006/12/08(金) 09:17:54AC_CHECK_HEADERSがヘッダを探すサーチパス、
AC_CHECK_LIBがライブラリを探すサーチパス、
は、
どこで定義されていて、
どうやったらそこに任意のディレクトリを追加できるのでしょう？
ドキュメントには記述が発見できず...
0190名無しさん＠お腹いっぱい。
2006/12/08(金) 14:19:020191名無しさん＠お腹いっぱい。
2006/12/08(金) 20:42:360192名無しさん＠お腹いっぱい。
2006/12/09(土) 22:48:56ありがとうございます。
/usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。
/usr/share を変更できない権限で configure 実行時にサーチパスを追加
する方法を探しています。
環境変数INCLUDEにセットしてみたり、
./configure INCLUDE=hoge
とかやってみているのですが、うまくいかずです。
0193名無しさん＠お腹いっぱい。
2006/12/13(水) 15:01:54main.c
./others
hoo.h
という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am
はどのように書けばいいのでしょうか？
0194名無しさん＠お腹いっぱい。
2006/12/13(水) 15:03:01./others
hoo.h
hoo.c
という感じです
0195名無しさん＠お腹いっぱい。
2006/12/14(木) 04:27:56環境変数で解決しました。
AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、
AC_CHECK_LIB は LIBS=-L<lib_dir>
で設定したディレクトリを探してくれるようです。
0196手元にある本から・・・
2006/12/16(土) 18:51:20GNU Autoconf/Automake/Libtool
ttp://www.amazon.co.jp/Autoconf-Automake-Libtool-Gary-Vaughan/dp/4274064115/
P48 6.5:よくある質問 から引用
ライブラリのソースが複数のサブディレクトリにあるとき、どうmakeしたらよいでしょうか？
ライブラリではほとんどの場合、libtoolコンビニエンスライブラリを使うことで簡単に解決できます。
しかし、プログラムについては簡単な解決策がなく、パッケージの構造の変更を選ぶ人が少なく有りません。
Automakeの次期メジャーリリースでは、この問題に進展があるはずです。
最新verならできるのかな？この本が翻訳された段階(平成13年)ではまだ無理っぽいみたいだし
0197名無しさん＠お腹いっぱい。
2006/12/16(土) 19:59:25ありがとうございます
どうにも良く分からないので
./src
main.c
./others
hoo.h
hoo.cpp
を、libothers.aとライブラリにして、./srcでリンクさせてます。（リンクが成功しないんですがこれは別問題かと）
うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか
0198名無しさん＠お腹いっぱい。
2006/12/16(土) 20:55:20今試したら少なくともautomake-1.9.5だと
うまくサブディレクトリを扱えるみたい
0199名無しさん＠お腹いっぱい。
2006/12/17(日) 04:04:490200名無しさん＠お腹いっぱい。
2006/12/17(日) 09:22:03とりあえず、、、試してみた。
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
0201198
2006/12/17(日) 18:48:32具体的もなにもmain.cのあるディレクトリのMakefile.amで
hoge_SOURCES=main.c others/hoo.h others/hoo.cpp
するだけだよ
othersにあるファイルも同じように扱えるようになったみたいなので
わざわざライブラリにまとめる必要はない
レスを投稿する
ニュース
- 円急落、34年ぶり158円台 日銀の政策維持で―ＮＹ市場 [蚤の市★]
- 【158.2】円、157円台に下落 日銀イベント通過で円売り安心感… ★3 [BFU★]
- 【社会】バイクが大型トラックの下敷きに、男性けが・・・信号待ち中に前方に移動してきたバイクに気づかず [あずささん★]
- 「なんで私があなたの子どものために」 広がる「子持ち様」批判 ★4 [蚤の市★]
- 円安の影響「大きくない」 日銀総裁、当面は緩和継続 ★4 [蚤の市★]
- 【芸能】有吉弘行 『炭水化物＋炭水化物』を悪者にした元凶に憤り 「どうせ痩せたモデルだろ！」「お好み焼き定食も別に変な事じゃない」 [冬月記者★]
- 【朗報】ジャグラーのピエロ、大相撲の化粧まわしだった [279254606]
- ドル円１５８．１８円 [455830913]
- ＡＤＨＤは行間が読めないからこの漫画が理解できないらしい [542840565]
- 大谷、7号ホームランwwwwwwwwwwwwwwwwwwww
- 【悲報】りりちゃん、めっちゃ裁判に怯えていた…🥺🥺🥺 [542840565]
- 【悲報】「新NISA」、いまだに国民の65%がやってないｗｗｗ専門家「未曽有の円安で今すぐ銀行預金から脱却しないと大変なことになる」 [661852521]