Autoconf,Automakeについて
>>99 ありがとうございます。 ところでprefixを/usrにするとどういうデメリットがあるのでしょうか? >>101 ごめんなさい。その通りMakefile.amの間違いです。 >>102 /usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。 /usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。 Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い (衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。 OSの一部として配布されるもの以外は/usrに入れないのが当り前です。 システム上重要というだけでなく、そのOSを使っている人の間で構成が 一致しているからでもある。 Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? もしだとすると>>102 のようになんでも/usrに叩き込むということになっちゃっ うのも納得できる。 >>104 の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。 寄せ集めっつーか、大多数のLinuxディストリにはbase systemと いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール したらそれもbase systemの一部だ」みたいなノリなんだろうね。 >>105 Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。 最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。 特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。 > Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? これは、もはや昔話だよもん。 libtool.m4に入ってるチェックで、Fortranコンパイラを勝手に探したり、 maximum length of command line argumentsとか言ってCPU食うのを やめさせたいんですけど。そういうACマクロはないんでしょうか? >>109 「勝手」にチェックする m4 なんてない。 configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。 気に入らなきゃチェックしてるところを外せ。 # それでまともにコンパイルできるとは思えんが。 えーと言い方が悪かったですが、AC_PROG_LIBTOOLマクロを使うと ほとんどのパッケージには不要なはずのチェックが盛りだくさんに はいるわけです。 とりあえず全部チェックしておけばどんな場合にも対応できるってこと なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、 そういうマクロあります?って話です。 libtool.m4が洗練されてないと言えばそれまでですがね。 >>109 AC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、 自分でlibtool.m4を書き換えちゃえば? うまく動く保証は無いし、libtool使う意味も減ると思うけど。 移植性考えないんならlibtool使わなくてもいいんじゃないかな? 移植性を考える考えないの二択ではないでしょう。全プラットフォームの 全項目を保証する気なんてないし、不可能ですから、どこまでチェック するかの問題ですね。AutoconfにしてもLibtoolにしても。 ですから「移植性考えないならlibtool使わなくていい」なんてのは極論です。 このチェックに関して言えば、ソースのビルド中にコマンドラインの 最大長を超えるコマンドは分割実行するようになっているみたいですが、 環境によっては数分以上かかるようなチェックをするより、4096とか 小さい値を決めうちしたほうがいいですね。実際そうしましたが。 コマンドに4096バイトも入らないプラットフォームは問題外ですから 無視でよいです。デフォルトがチェックになってるのは仕方ないですが。 外してたら済まんが、ac_cvなんとかでスキップできんの? たかだか AC_LIBTOOL_SYS_MAX_CMD_LEN のチェックぐらいで数分もかかる プラットホームは俺の中で問題外なんだけどなw 何のために libtool 使ってんのか分からんよ。 >>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がうまく動かない(泣) autoconfのドキュメント読んでたら、 $ ./configure --lt_cv_sys_max_cmd_len=4096 でいけるかもしれんような気がした。 しかし、試せない。。。 やっと試せた。 >>118 > $ ./configure --lt_cv_sys_max_cmd_len=4096 ではなく、 $ ./configure lt_cv_sys_max_cmd_len=4096 だね。 すぐ上でされてるみたいだけど、とりあえずやってみれば? 問題があれば誘導されるでしょ。 configureのコストが、高機能になればなるほどデカクなってきてる わけですが、これらを動的にチェックするんじゃなくて静的にデータ ベースのようなもので持たせることはできないですかね。とはいっても 何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう わけでなかなか難しいんだろうけど。 >>122 そのためにはconfig.siteを使えばいいと思うんだけど。 >>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がリンクされます (続く) 対して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が変わるのかがわからないのですが、どこを調べれば いいのでしょうか? >>125 二つの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のほうが新しい方を選択しそうですよね。 偉そうに書いておきながら、よく分からんです。 識者の降臨をお待ちします。 みなさん、すいません。 わからんわからんといいながら、解決してしまいました。 書き込みで両方のログをコピペしたときに、両方の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というより、なんかリンカの問題点だったような気もしてきた。 みなさん、お騒がせしました。 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 に記述させる方法 を教えて下さい。 >>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 ヴァージョンがたくさんあるのは、上の方で言われている通り、 後方互換性(backward compatibility)が維持できていないからですね。 使いにくいのは>>81 さんの通りかと;-) 教えてください。以下のようなソースがあるとして、 ・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に関係するソースを無視させるにはどうやったら良いでしょうか? >>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 あたり。 >>134 キモはAM_CONDITIONALとifの組み合わせだったのですね。 やりたいことが実現できてすっきりです。ありがとうございます。 あるプログラムは C、あるプログラムは シェルスクリプト、あるプログラムは Perl を使って書かれた パッケージを autoconf, automake でインスコさせたい時、 シェルスクリプトとか Perl に関する指示はどう出せばいいんですか? Makefile.amに bin_SCRIPTS = fugafufu.pl とか? AC_CHECK_SIZEOF(wchar_t) の結果を Makefile(.am) 内で知りたいのだが、 何かうまい方法はないもんですかね・・・。 (wchar_t のサイズが Linux と Cygwin で違うから、コンパイルするファイルを 振り分けたい、というのが動機です) まだあったのか、このスレ。 >>138 make組ハケーン >>139 AM_CONDITIONAL >>140 レスどうもでつ。 結局 AC_CANONICAL_HOST で逃げることにしますた。 -lhogeでstatic-linkさせる方法を教えて下さい。 >>143 自作のライブラリなら, hoge_LDFLAGS = -static をMakefile.amに追加するのかな? make時なら,./configure --helpして それなりのオプションがあれば可能だと思う. 共有ライブラリのバージョンが違っても動くプログラムを作る方法を教えて下さい 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等の指定の仕方が変わったのでしょうか? #なにか指定し忘れてるのだろうか,,, >>147 libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか? 確か最近のAutotoolsは同じprefixにしないと問題があるとMLに流れていたと思います。 # ググってもCygwin関係の話しか出てこない (^^; 確認してみてください。 また、(2)の最初の環境ではそのような問題は無いと思うので、 一度、buildディレクトリをクリーンにして試してみてください。 make maintainer-clean だったっけ? その後で、autoreconf -f -i -Wall してみてください。 autoconfとautomakeのバージョンによっては、 autoreconfがうまく動作しないかもしれないので、 そのときはちょっと困ります。 config.logあたりに何故できないかの情報があるかもしれないので、 ながめてみてください。 >>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 を使っていようと思います。ありがとうございました。 >>149 あまりお役に立てなかったようで、、、 後は、ソースからビルドされたようなので、 libtoolのmakeに失敗している可能性もあるので、 libtoolをmakeしたディレクトリでmake checkして、 問題が無いか確認するぐらいかな? ↓の書き込みも漏れだったりするけど、多分これだと思う。 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 も入るみたいだけど? autopoint で i18n 化した場合って、GPL 互換のライセンスにしないと駄目なの? intl/ の下に出来るファイルは全部 GPL だよね? ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。 >>154 info gettextのDiscussionsの * Dependencies over the GPL or LGPL に[The simplest answer is "normally not".]と書かれている。 一応、読んでみてね。 >>155 thx。でも英語が分からん…_| ̄|○ 一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも 配布できるという解釈で OK? よくわからんが、intlの下ってlibintlに入るものと同じなんでしょ? 削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの? こんにちは。 以下のようなツリーで 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 ツリーのみ: / ┃ ┣[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 >>159 subB1.oをリンクし忘れてるとか リンクの際に引きわたす.oの順番を変えてみるとか Makefile.am での”xxx_LIBRARIES =, xxx_SOURCES =”や configure.in での”AC_CONFIG_FILES()”以外に、 リンク先の指定方法があるのでしょうか?? なんとなく、各 Makefile.am でリンク先の指定とか できそうに思うのですが、調べても判りません orz。 >>159 なんでそんな不思議な事を… programBのツリー内でlibprogramB.aでも作ればいいんじゃない 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 ■ 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 >>164 共通部分はライブラリにしてしまうのがいいと思うのだが、 後、SOURCESなどでは相対パスではなく、$(top_srcdir) などを利用するのが、最近の流儀です。 # configureを任意のディレクトリで実行可能にするため。 また、SUBDIRSがサブディレクトリではないのも問題になるかも しれません。 パッケージ構成を再検討したほうがいいと言うのに私も賛成。 自己解決しました。 *.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで なかったのが原因のようですた。これで make が通るようになり pgA が 出来上がったのですが、いまいち腑に落ちないです。なんかちょっと 書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。 まあ、自分が悪いのですが。 お答えいただいた皆さんありがとう ございました。 http://www.ossp.org/pkg/tool/lmtp2nntp/ これなんですけど、LIBS って環境変数を設定してたら、configure に失敗します。 メインの configure で LIBS を自分用にライブラリ追加して設定してるんだけど、 サブの configure にLIBSが環境変数だから引き継がれて悪影響が出てる。 これって、どれ? 1. LIBS を環境変数として指定するのは間違い 2. メインの configure.ac の書き方がまずい 3. autoconf なんてそんなもの >>168 LIBSをunsetしてから LIBS=hoge ./conifgure とすると、サブのconfigureに引き継がれないという噂が 利用できるかもしれないが、そうでなければ、 > 1. LIBS を環境変数として指定するのは間違い かな? > 3. autoconf なんてそんなもの これの気もするが、、、 > LIBS=hoge ./conifgure だめみたい。 うーん、configure.ac で LIBS="$LIBS_EXTRA $LIBS" するのを止めて、Makefile.in で、 LIBS = @LIBS_EXTRA@ @LIBS@ しないとだめなのかなぁ。 ぶー、ぶさいく。 ちらしの裏に書いて置くべきことなは、 承知のうえで、あえて、誰かに聞いてもらいたい。 Autoconf,Automake,libtoolのおかげで、コンパイル、インストール は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ って思うときに、なんかわけわからなくて。 makefileを自作してたりする。んでそれが面倒なんでソース弄るのも おっくうになってたり。 みんなはどうしてるの? 自分で書くCソースはそもそもそんなに複雑じゃないので、 autoconfを使わなくてもMakefileはOSに依存せず、 異なるOS間でも共通(同一)になることが多い。 なので、Makefileを自分で直接書いてる。 もしくは、もっと簡単なソースだとMakefileすら要らず、 makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。 >>172 使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので それを自動化したprepare_projectなるスクリプトを書いて使ってる autoconfは便利だしとっつきやすいが、 automakeまで手を伸ばすのはちと面倒なんだよな。 どうせ最初から使う必要なんてないんだから、 必要を感じてきたらそのとき導入すればいいよ。 >> prepare_projectなるスクリプト MS的にいうとautotools_wizardだね >>175 autoconf単独よりautomakeとセットで使う方が断然らくちんだべや NFS上でaclocal等を実行すると、perlがflock使っているところで 止まるんだけど、これってperlを-Ud_flock付きでコンパイルする 以外に方法はないのでしょうか? (aclocalは1.9.6) 型のサイズが違ったらエラーを出すようにしたいのですけど、 どうしたらいいでしょうか。 configure.inに AC_CHECK_SIZEOF(int) AM_CONDITIONAL(CHECK_INT, test "$SIZEOF_INT" = 4) Makefile.amに if !CHECK_INT endif と書いてみたのですけど、if〜endifの間の書き方が分かりません。 よろしくお願いします。 >>179 configureの時点で止めてしまうって話でいいのなら、下の感じだとおもう。試してはいないけど。 AC_CHECK_SIZEOF(int) if test $SIZEOF_INT != 4; then AC_MSG_FAILURE([aaaa]) fi >>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 としてみたらうまくいきました。ありがとうございました。 autoconf-archive http://autoconf-archive.cryp.to/macros-by-category.html を見ていると、マクロの先頭が、AC,ACX,AXなどいくつかありますが、 それぞれどのような違いがあってつけられているのでしょうか。 automake-1.10が出たので、autoconf-2.60とともに試しにいれてみた。 ついでにm4-1.4.6にしてみた。古いautoconf関係との解離は大きくなった感じ。 あと、autoconf-2.60のmake checkでエラーになるのだが、 これは、m4-1.4.6のせいで、autoconf-2.60aにするといいらしい。 とりあえず、こんな状況。 --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 変更したら解決できました。 ありがとうございます。 AC_CHECK_LIBに/usr/local/libなどのディレクトリも見てもらうようにするには どうしたらいいんでしょうか? そもそも、 AC_CHECK_HEADERSがヘッダを探すサーチパス、 AC_CHECK_LIBがライブラリを探すサーチパス、 は、 どこで定義されていて、 どうやったらそこに任意のディレクトリを追加できるのでしょう? ドキュメントには記述が発見できず... apacheやqmailみたいに1パッケージに複数のアプリケーションが含まれているようなソースツリーの場合にいい感じにconfigureを量産してくれるようなautotoolsが欲しい。 /usr/share/autoconf とかその辺にあるよ >>191 ありがとうございます。 /usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。 /usr/share を変更できない権限で configure 実行時にサーチパスを追加 する方法を探しています。 環境変数INCLUDEにセットしてみたり、 ./configure INCLUDE=hoge とかやってみているのですが、うまくいかずです。 ./src main.c ./others hoo.h という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am はどのように書けばいいのでしょうか? すいません書き忘れです。 ./others hoo.h hoo.c という感じです >>192 環境変数で解決しました。 AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、 AC_CHECK_LIB は LIBS=-L<lib_dir> で設定したディレクトリを探してくれるようです。 >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年)ではまだ無理っぽいみたいだし >>196 ありがとうございます どうにも良く分からないので ./src main.c ./others hoo.h hoo.cpp を、libothers.aとライブラリにして、./srcでリンクさせてます。(リンクが成功しないんですがこれは別問題かと) うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか >>196 ,197 今試したら少なくともautomake-1.9.5だと うまくサブディレクトリを扱えるみたい 具体的な書き方が分からないのですが、教えていただけませんか? >>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 >>199 具体的もなにもmain.cのあるディレクトリのMakefile.amで hoge_SOURCES=main.c others/hoo.h others/hoo.cpp するだけだよ othersにあるファイルも同じように扱えるようになったみたいなので わざわざライブラリにまとめる必要はない >>200 >>201 ありがとうございます。 確かにmainのあるディレクトリでothers/hoge.cppと指定すれば出来ました。 しかし、サブディレクトリに物凄くファイルがあるので、階層別にMakefileを作り、ライブラリにしたほうが管理しやすそうに思えます。 あと、>>200 さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか? それともnoinst_LIBRARIESにした方がいいのでしょうか? >>202 > あと、>>200 さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか? > それともnoinst_LIBRARIESにした方がいいのでしょうか? ほかで利用するならインストールするけど、そうでなければ デフォルトでstaticにしないと不味いかもしれません。 他で使うなら、include_HEADERSにヘッダを書かなきゃだめですが、、、 判断できない場合は、とりあえずインストールするのが無難です。 # libhoo.laはデバッグ時に必要です。 > libhoo.laはデバッグ時に必要です。 *.laって何するものなの? >>204 > *.laって何するものなの? $ libtool gdb hogehoge ってやるとき、参照するライブラリが書かれているテキストファイルだと 思っているのですが、、、 識者の方ツッコミよろ。 noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。 AC_CHECK_HEADERなどで宣言されるHAVE_*の先頭に識別子をつけることはできる? #define HOGE_HAVE_MEMORY_H となるような。 hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが ライブラリを使う側にHAVE_*が影響してしまうので ライブラリのコンパイル後に消すか、名前を変えるかしたい。 しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので 単純にconfigヘッダーをインストールしないというわけにもいかず。 >207 とりあえず、autoconf-2.61 でだけど。 本論と関係ないけど、AC_CHECK_HEADER は HAVE_* を自動で定義してくれなくて、AC_CHECK_HEADERS が、HAVE_* を自動で定義してくれるような。 で、 AC_CHECK_HEADER(test.h, AC_DEFINE(HOGE_HAVE_TEST_H, [], [Define to 1 if you have the <test.h> header file.])) みたいな感じで自前で書けばいいと思う。autoheader も拾ってくれてるみたいだし。 デフォルトで定義されてしまう分(configure 自体に使用される)についても名前を差し替えたい場合には、_AC_INCLUDES_DEFAULT_REQUIREMENTS か AC_INCLUDES_DEFAULT の再定義が必要。 ここまで書いて思ったんだけどさ、ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない? ライブラリのヘッダでconfig.hを読むってのが変だと思うけどなあ。 >>208 どうも。 AC_CHECK_HEADERSで自己定義して、定義しても自動ででてるーと思ってました。 AC_CHECK_HEADERならでないのですか。 >>209 例えば、 #if HAVE_INTTYPES_H #include <inttypes.h> #elif HAVE_STDINT_H #include <stdint.h> #else # ..... 自己定義 #endif #if HAVE_SYS_STYPES_H #.......略 typedef size_t my_size_t ; typedef uint32_t my_uint32_t ; typedef struct libraryargs { my_size_t length; my_uint32_t data; } libraryargs; DECLARE_EXPORT my_bool_t library_function(libraryargs *args); というのがあると、size_tやuint32_tが実際なに型なのかconfigureで作ると思っていて その結果をライブラリコンパイル時に使っているので ライブラリを使う側も同じ型を使って欲しいと思うんです。 それをまた#ifdef _WIN32でやっているとconfigureの意味が無いというか。 普通どうやるんでしょ? >>208 >ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない? 動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。 Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。 不要なものをhoge_config.h.inから削除するとhoge_config.hに反映されないことに気づきました。 >>210 ライブラリのヘッダファイルであるかどうかわからないtypedefをさらにtypedefって あまり見ないような。大抵自分で型を判断してやってないか。 >>213 自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで つまり4バイト数値型はhoge_intとかですか。 それがconfigureでやることではないのですか? >>214 そのライブラリを使うアプリのconfigureでやればいいんでない? そういう話では無いのかな >215 ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、 そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。 その上で、ヘッダ側では #ifdef HAVE_CONFIG_H #include <config.h> #endif しておけば OK かな。 >>216 うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。 hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。 結構面倒な作業になるのかもしれないけど、、、 まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、 どっちが良いかはよく分からないです。 CFLAGSとCPPFLAGSの違いがよくわかりません Cプリプロセッサフラグってどういうことでしょうか? -I/fuga/fuge/ をコンパイル時に指定したい場合、 CFLAGS=-I/fuga/fuge/ だと追加されなくて CPPFLAGSに指定すると追加されてました。 ちなみにC++のファイルです。 なぜそこで > Cプリプロセッサフラグ という自分の推測が間違っているということを疑わないのか。 いや、推測じゃないです。 http://sources.redhat.com/automake/automake.html で CPPFLAGS C/C++ preprocessor flags となってます。 まず問いたい。 おまえはそれを見て、それが正解だと推測したわけだよな? 公式のマニュアルではなく、なぜそんな下らんもので推測したんだ? ありがとうございます。 プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。 C++でのオプションはCXXFLAGSで指定します。 サンクスでした まず問いたい。 >という自分の推測が間違っているということを疑わないのか。 という発言が出てくるのか。 CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか?w bin_PROGRAMS=/tmp/fuga とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか? できるかどうかわからないけど、なぜそういうことをしたいのか の目的がわかれば、別の解決法が出てくるかもね。 自分のホームディレクトリにソースがあったとしても、 /tmp/でmakeしたいんです。 /home/my/src/"ここにソースがある" けど、makeを叩くことで、 /tmp/でビルドさせたいんです。 >>227 > 自分のホームディレクトリにソースがあったとしても、 > /tmp/でmakeしたいんです。 /tmp で/home/my/src/configure すれば、/tmp以下にMakefileができると思うけど。 そういう話ではない? Makefileの中身が相対パスで書かれてるみたいなので、 /tmpでmakeをしてもエラーが出るんですよね・・・ やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が 早いですかね? それは多分そのプログラムの方が悪い(autotoolsの使い方の問題)。 tmpに全部コピーした方が早そう。 >>231 srcdir や top_srcdir への相対パスなら大丈夫だけど、 # 絶対パスならabsを付ける カレントディレクトリからのパスになってるんじゃない? prog_SOURCESにカレントディレクトリ以外のファイルを以下のように指定すると my_src_dir=/home/xxx/src/ prog_SOURCES=$(my_src_dir)test.c 生成されるMakefileに include ./$(DEPDIR)/prog-$(my_src_dir)test.Po という記述がされて、 ./deps/prog-/home/xxx/src/test.Po を見に行ってしまいエラーになってしまいます。 回避する方法ってありますか? >233 my_src_dir=/home/xxx/src prog_SOURCES=$(my_src_dir)/test.c だったら通ったりしない? って絶対パスじゃないと駄目なの?そーいうのはソースじゃなくてライブラリにしないか? あちこちにあるファイルを集めて一つのディレクトリツリーを作りたいんですが、 なんかうまいやりかたは無いんでしょうか a/b/c/hoge : d/e/hoge install ... a/b/c/huga : f/g/huga ... とか延々と書くのが面倒臭いんです... >>234 ダメなんです。なぜかそういう風に展開されちゃうんですよね・・・ 同じソースファイルを使って、実行ファイルと共有ライブラリを 作りたいのですが、 ‘created with both libtool and without’エラーが吐かれて、 うまくいきません。 http://www.gnu.org/software/automake/manual/html_node/Libtool-Issues.html の8.3.9.2 Objects ‘created with both libtool and without’ に解決らしき記述があるのですが、意味がわからず困っています。 どうしろと書いてあるのでしょうか? >>237 そこの > A workaround for this issue is 以下をていねいに読めばだいたいわからんかな? prog_CFLAGS = $(AM_CFLAGS) を追加して、副作用として prog.c と foo.c が prog-prog.o と prog-foo.o に コンパイルされるようにする(そうすることで、ライブラリのほうの オブジェクトファイルと、名前がぶつからないようにする)、とある。 linuxなんですがAutoconf,Automakeについて質問してもいいですか? llvm bitcodeを中間コードとしてビルドするようなmakefileをautotoolsで作れませんかね? Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool ttp://books.google.co.jp/books?id=HBbKghM2fGYC&dq=Autotools&hl=ja&source=gbs_navlinks_s ぐぐったら入力途中で候補にautoconf with vs enableというのが出てきたので その結果を見てみたらいろいろと議論はあるようだ。 https://mail.python.org/pipermail/python-dev/2001-January/011991.html ここの解説だと、機能の有無を決めるのにenable、依存するパッケージとかの 指定にwithを使うという感じみたい。それでも例外もあるようだ。 >>246 構文はそっくりだけど意味は違うよ、適切に使い分けてね って事かな…? 今回はpackageの有無で機能を切り替えるので--with-*を使うことにするわ、サンクス! キター! From: Stefano Lattarini <stefano.lattarini@gmail.com> To: Automake List <automake@gnu.org> Cc: info-gnu@gnu.org, autotools-announce@gnu.org 日付: 2015年1月6日 19:19 件名: GNU Automake 1.15 released We are pleased to announce the GNU Automake 1.15 minor release. (snip) Download here: ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz 2年ぶり! From: Mathieu Lirzin <mthl@gnu.org> To: <automake@gnu.org> Subject: GNU Automake 1.15.1 released Date: Mon, 19 Jun 2017 22:50:34 +0200 Message-ID: <87shivem79.fsf@gnu.org> We are pleased to announce the GNU Automake 1.15.1 maintenance release. 誰でも簡単にパソコン1台で稼げる方法など 参考までに、 ⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。 グーグル検索⇒『宮本のゴウリエセレレ』 CAEY39R21B 知り合いから教えてもらったパソコン一台でお金持ちになれるやり方 時間がある方はみてもいいかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 CGFTL 過疎化してますね、このスレ. From: Jim Meyering <jim@meyering.net> To: info-gnu@gnu.org Subject: automake-1.16.2 released [stable] Date: Sat, 21 Mar 2020 17:51:38 -0700 Message-ID: <m2eetlp5yd.fsf@meyering.net> List-Archive: <https://lists.gnu.org/archive/html/automake> ; Cc: automake@gnu.org This is to announce automake-1.16.2, a stable release. There have been 38 commits by 12 people in the two years (almost to the day) since 1.16.1. Special thanks to Karl Berry for doing a lot of the recent work preparing for this release. See the NEWS below for a brief summary. このスレ見てる人いるんだろうか? From: Jim Meyering <jim@meyering.net> To: autotools-announce@gnu.org, automake@gnu.org, info-gnu@gnu.org Subject: automake-1.16.3 released [stable] Date: Wed, 18 Nov 2020 20:51:52 -0800 Message-ID: <m28sayuexj.fsf@meyering.net> List-Archive: <https://lists.gnu.org/archive/html/autotools-announce> ; This is to announce automake-1.16.3, a stable release. There have been 62 commits by 15 people in the 35 weeks since 1.16.2. Special thanks to Karl Berry and Zack Weinberg for doing so much of the work. See the NEWS below for a brief summary. Thanks to everyone who has contributed! 誰も気にしてないと思うが、今月autoconfが新しくなった。 https://lists.gnu.org/archive/html/autoconf/2020-12/msg00002.html To: info-gnu@gnu.org, autoconf@gnu.org Subject: autoconf-2.70 released [stable] Message-Id: <4Cr8xf5THLzcbc@panix1.panix.com> Date: Tue, 8 Dec 2020 14:14:30 -0500 (EST) From: Zack Weinberg <zackw@panix.com> We are pleased to announce stable release 2.70 of GNU Autoconf. This release includes eight years of development work since the previous release, 2.69. Noteworthy changes include support for the 2011 revisions of the C and C++ standards, support for reproducible builds, improved support for cross-compilation, improved compatibility with current compilers and shell utilities, more efficient generated shell code, and many bug fixes. See below for a detailed list of changes since the previous version, 2.69, as summarized by the NEWS file. Unfortunately, we were not able to maintain perfect backward compatibility with existing Autoconf scripts. Caution is advised when upgrading. The list of changes, below, includes detailed explanations and advice for all of the compatibility problems we know about. Please report bugs and problems with this release to the Savannah bug tracker: https://savannah.gnu.org/support/?func=additem& ;group=autoconf Please also send general comments and feedback to <autoconf@gnu.org>. もはや追いかける者もいなくなったか。 https://lists.gnu.org/archive/html/autoconf/2021-01/msg00126.html From: Zack Weinberg Subject: autoconf-2.71 released [stable] Date: Thu, 28 Jan 2021 17:49:17 -0500 (EST) We are pleased to announce stable release 2.71 of Autoconf. 2.71 is a bugfix release, correcting several important compatibility problems and regressions discovered since the release of 2.70. There are no new features. Upgrading is recommended for all users of 2.70. Users of 2.69 or earlier should proceed with caution; please consult the NEWS file and/or the release announcement for 2.70 for details. Here are the compressed sources: https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz (2.0MB) https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz (1.3MB) Here are the GPG detached signatures[*]: https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz.sig https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz.sig NEWS * Noteworthy changes in release 2.71 (2021-01-28) [stable] ** Bug fixes, including: *** Compilers that support C99 but not C2011 are detected correctly. *** Compatibility improved with clang and Oracle C++. *** Compatibility restored with automake's rules for regenerating configure. *** Compatibility restored with old versions of std-gnu11.m4. Announceメールjもろくに流れなくなったかわいそうなAutomake。 From: Jim Meyering Subject: [automake-commit] annotated tag v1.16.4 created (now 048bc0d) Date: Mon, 26 Jul 2021 15:38:41 -0400 meyering pushed a change to annotated tag v1.16.4 in repository automake. at 048bc0d (tag) tagging 39c0005a1aadefdace6f2c741f8fd8a84e60f0f1 (commit) replaces v1.16.3 by Jim Meyering on Mon Jul 26 12:34:11 2021 -0700 人手が足りていないらしい。 https://www.gnu.org/software/automake/ New volunteers to help maintain Automake are needed. Please help if you can. https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html From: Karl Berry Subject: automake bug fixers/developers needed Date: Fri, 26 Mar 2021 16:39:04 -0600 For about the last year, I've been the main person applying bug fixes to (or at least reading bug reports for) Automake. My pace has been quite slow, but since maintenance was almost completely lacking for some years before that, I've been doing what I could. Mainly, going through the old bug reports and dealing with the "easy" ones, besides trying to handle new ones as best I can. There are still many outstanding bug reports that I have not even read. Unfortunately, I am going to have even less time for Automake for the foreseeable future. I will still do what I can, but it will not be much. Therefore, if you have some automake/perl/shell/make/etc. development skill or interest, and are also interested in Automake maintenance continuing, please volunteer if you can. I recommend starting by looking at the open bug list: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_4 彼女←隠すならぜんぜんいい マネージャーはクビだろうな じゃキンプリはないんじゃないかな 実質賃金だけでも ニコ生は中抜きがえげつない そんなん言ってスクエニ辞めて 戦争がしたいなら脱退してくれ みんなでオッパの帰りを祈りましょう🙏❤ 貧乏なのでぇNISA枠でデイトレすればいいのに xzの穴にautoconfの難読度が利用されてしまいましたなあ read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる