02/07/08 22:40.net
>>29
> JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな?
> 最低限 make と make install と make dist を使えるようにしたいのだけど。
Automake-1.6.2とAutoconf-2.53だと、gcjを利用したコンパイルができるみたい。
でも、うちはJAVAの環境が無いから試せないです。
automakeのinfoの、ノード"Java Support"を参照してみてください。
31:29
02/07/08 23:37.net
>>30
gcjを入れてみたけどlibgcj.specが????とか出て動かない。かなり険しそう(w
とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
javacで動くように試してみます。
32:名無しさん＠お腹いっぱい。
02/07/09 00:18.net
>>31
> とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
> javacで動くように試してみます。
1.4のやつって、javacでのコンパイルのみのサポートだったと思います。
# 記憶が曖昧ですみません。
info にもありますけど、.javaと.classのサフィックスルールを自動的に作れ
ない(ファイルの中からクラス名を調査する必要がある)のでそのような仕様だっ
たと思います。だからmakeはできてもmake installは難しいと思います。
# でもうまくいったら教えてください。
33:名無しさん＠お腹いっぱい。
02/07/21 10:19.net
Autoconf-2.53b 開発版リリース（結構前だけど）
どーでもいいけど、autoconf-mode.elとかautotest-mode.elとかあるのね。
色が変わるだけみたいだけど。
34:名無しさん＠お腹いっぱい。
02/10/02 22:22.net
知らない間にac-2.54 am-1.7になってたのね。
amのdrilistって便利そうなんだけど使っている人いる？
--confiugre=$HOMEしている人ぐらいなのかな。
# ム板のmmmpスレのほうが活発かな？
35:名無しさん＠お腹いっぱい。
02/10/27 01:33.net
36:名無しさん＠お腹いっぱい。
02/12/17 00:13.net
保守
37:山崎渉
03/01/15 13:25.net
（＾＾）
38:名無しさん＠お腹いっぱい。
03/02/01 12:17.net
autoconfは便利なんだけど、これに対応するようになってから
ソースの見通しが悪くなった。
39:名無しさん＠お腹いっぱい。
03/02/01 21:24.net
前は環境依存部分を別関数にしたりしてたけど、最近は面倒だからやめた。
確かに見通しは悪くなった。GNUのソースも見るのが辛くなってきた。
# なんか愚痴ばっかりだな。
40:名無しさん＠お腹いっぱい。
03/02/07 11:03.net
この前からCommon Lispで書かれた数式処理ソフトウェアの構成を
追ってみようとしてるんだけど、main関数のないLispソースを
autotoolsでビルドする構成になってるので、さっぱり分からない。
Autotoolsを使うときには、想定しているコンパイラ・ライブラリの組み合わせと
依存関係を簡単にドキュメント化してくれないと困ってしまう。
逆に移植などがし辛くなってしまうよ。
41:名無しさん＠お腹いっぱい。
03/02/07 18:55.net
>>40
とりあえずconfigureしてlog見るんじゃだめなの？
Common Lisp知らないからいい加減なこといっているけど。
42:名無しさん＠お腹いっぱい。
03/02/10 18:50.net
コンパイル型言語じゃないからね、Lispの「メモリダンプ」とかって独特なんです。
で、どんなコマンドが実行されてるんだか
（というか、山ほど実行されてるコマンドのうちどれが重要なのか）分からない。
43:名無しさん＠お腹いっぱい。
03/02/10 21:21.net
いろいろ大変なんですね。LispはEmacsのしか知らないし、
AM_PATH_LISPDIR使っているものしか見たこと無いんで、
役に立たずですまんです。
# autoconfにもLispファイルがあります。
44:名無しさん＠お腹いっぱい。
03/03/19 10:04.net
Autoconf,Automake,Libtoolを解説してる本って少ないながらも一応あるようですけど，
どんなもんでしょう？いい本なのでしょうか？
45:名無しさん＠お腹いっぱい。
03/03/19 20:26.net
多分あの本だと思いますがいい本です。ただし、最新のAutoconf、Automakeを
利用するとちょっと戸惑うかもしれません。セレンディップのGNOMEプログラ
ミングという本にもこれらの解説があります。
46:名無しさん＠お腹いっぱい。
03/03/19 22:57.net
オーム社の本の事ですか？
47:名無しさん＠お腹いっぱい。
03/03/19 23:47.net
>>46 そうだと思う。
んでも、少々高いから、漏れは立ち読みで逝こうかとｗ
48:名無しさん＠お腹いっぱい。
03/03/19 23:59.net
やっぱりm4マクロの勉強からかな
49:名無しさん＠お腹いっぱい。
03/03/28 06:27.net
>>48
勉強ってほどのもんでもない。
50:名無しさん＠お腹いっぱい。
03/04/04 19:56.net
２割、３割はあたりまえ。
51:山崎渉
03/04/17 12:14.net
（＾＾）
52:あぼーん
あぼーん.net
あぼーん
53:名無しさん＠お腹いっぱい。
03/05/15 03:41.net
CVSにconfigureまで突っ込んでるプロジェクトもたまに
ありますが、ふつうはどこまで含めるものなんですか。
54:名無しさん＠お腹いっぱい。
03/05/15 14:14.net
FreeBSD PORTS なんかだと、
autoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、
古いバージョンも後生大事に用意されていますよね。
これは何故なんでしょうか？
何か後方互換性に大きな問題でもあるのでしょうか？
55:名無しさん＠お腹いっぱい。
03/05/15 16:23.net
はい。
56:名無しさん＠お腹いっぱい。
03/05/15 16:35.net
>>55
なるほど。
そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、
といった判断は一般にどのような基準に基づいて行えば良いのでしょうか？
57:名無しさん＠お腹いっぱい。
03/05/15 17:36.net
>56
違うバージョンを使うと動かないので悩む必要はありません。
58:名無しさん＠お腹いっぱい。
03/05/15 19:54.net
>>57
う～ん、やっぱり良くわからないです。
とどのつまり、知りたいのは、
PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、
とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか？
それとも、古いバージョンのも入れておいた方が良いのでしょうか？
59:名無しさん＠お腹いっぱい。
03/05/15 19:59.net
>>53
configure.acまでと言いたいが、今のAutotoolsのバージョン間の互換性から、
configureまで入れておいたほうが無難。誰でもcheckoutできるプロジェクト
なら、「autoconfを実行するとエラーが出ます」というレポートが大量発生す
る可能性が高い。しかし、confugure.acやMakefile.amを書き換えると同じ状
況になるんだよね。
AM_INIT_AUTOMAKE([1.7])とかAC_PREREQ(2.57)とか書けばいいのかな？
60:名無しさん＠お腹いっぱい。
03/05/15 20:06.net
>>58
Autotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。
他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが
あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー
スを書いた人が使っているものと同じバージョンがないとうまく動かないこと
もあります。更に、これらのツールは同じprefixにインストールしないとうま
く動かない場合が多いです。
私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、
libtoolだけはいい方法が見つからないです。
61:>>53
03/05/16 01:00.net
>>59
さんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。
すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。
configureはtarballに入れればいいし。
62:名無しさん＠お腹いっぱい。
03/05/16 02:39.net
>>60
どうもです。
私はとくに他人のプロジェクトに参加したりということもなさそうですので、
最新のを入れて問題なさそうですね。
63:名無しさん＠お腹いっぱい。
03/05/17 02:40.net
とあるソフトの configure.in、
AC_SEARCH_LIBS(tputs, ncurses termcap, HAVE_TERMCAPとdefine, ダメです)
みたいなライブラリチェックしかなくてSolaris8上でのconfigureが不能です。
対症療法よりもその辺全面的に書き換えようと思うんで、
configure.in での termcap, curses, ncursesのチェックのお手本になるソフト探してます。
readlineをリンクすることも可能で、Solarisでconfigure;make 可能なソフト、
なんかないでしょうか？gdb?
64:名無しさん＠お腹いっぱい。
03/05/17 11:11.net
>>63
GNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。
infoコマンドのソースはgdbより少ないかな？
65:63
03/05/17 18:27.net
>>64 情報ありがとうございます。当たってみます。
66:名無しさん＠お腹いっぱい。
03/05/19 21:08.net
済みません、ちょとお邪魔させてください。
事情により初めてautoconf/automake使い始めたとこなんですが、
unyalib--------------------subDirA
ソ ースいくつか | ソースいくつか
|
|
|-----subDirB
ソースいくつか
という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、
なおかつ、そのライブラリの一部になっているサブディレクトリにも
ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、
67:名無しさん＠お腹いっぱい。
03/05/19 21:08.net
解説ページとかを参考にして、
-- unyalibのMakefile.am ------
SUBDIRS = subDirA subDirB
noinst_LIBRARIES = libunyalib.a
libunyalib_a_SOURCES = unya.c honya.c
-- subDirAのMakefile.am ----
noinst_LIBRARIES _ libunyalib.a
libunyalib_a_SOURCES =
libunyalib_a_LIBADD = unya_a.c honya_a.c
-- subDirBもsubDirAと同じように"LIBADD"を使用 ----
とかいうように、書いてautomakeを動かしてみました。
でも、結果としてのMakefile.inは、どのディレクトリのものでも
unyalib.a: $(unyalib_a_OBJECTS) $(unyalib_a_DEPENDENCIES)
-rm -f unyalib.a
$(AR) cru unyalib.a $(unyalib_a_OBJECTS) $(unyalib_a_LIBADD)
$(RANLIB) unyalib.a
と、ar の前に必ずrm が実行されて、一つのライブラリに合体してくれない状態です。
サブディレクトリの方ではrmの実行が挟まれず、一つのライブラリにさせる技は無いでしょうか。
68:あぼーん
あぼーん.net
あぼーん
69:名無しさん＠お腹いっぱい。
03/05/19 21:50.net
そりゃサブディレクトリでやったらそれぞれ別物だし、
一つのライブラリになるわけはない罠。
70:67
03/05/19 22:48.net
えーと、やっぱ駄目ですか。
automakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、
一つのディレクトリに集まっているというのしか想定していないということでしょうか。
71:名無しさん＠お腹いっぱい。
03/05/20 20:14.net
SUBDIRS使わずに、SOURCESで相対パス指定でできなかったっけ？
$(topsrcdir)とかで指定するんだったかも。
1.4頃の記憶なんで違うかもしれん。
どっちかというとlibtoolsの話かもしれんけどね。
72:67
03/05/21 21:31.net
やってみました。
SUBDIRS無し、
libunyalib_a_SOURCES = unya.c honya.c subDirA/unya_a.c subDirA/honya_a.c
とかしてみると、
subDirA下のソースに対するオブジェクトがunyalib(ライブラリソースツリーの根っこ)下に
作成されるけど、ライブラリのためのオブジェクトはサブディレクトリから取ってこようとする
Makefileが出来ちゃいまひた。
で、もう、最初のMakefile.inはautomakeで作るけど、
それを手で修正して以後automakeは使わないという決定が
本日なされちゃって、この件は棚上げとあいなりました。
ありがとうございました。
73:名無しさん＠お腹いっぱい。
03/05/21 23:35.net
>>1
使いにくいのを奥深さと勘違いしてるだけだろ。
74:>>53
03/05/21 23:52.net
>>73
奥が深くて使いづらいと申し上げているのです。
75:あぼーん
あぼーん.net
あぼーん
76:あぼーん
あぼーん.net
あぼーん
77:名無しさん＠お腹いっぱい。
03/05/23 15:15.net
makeができない。
78:名無しさん＠お腹いっぱい。
03/05/25 02:38.net
automakeで作ったMakefileってgmakeに依存する?
79:名無しさん＠お腹いっぱい。
03/05/25 20:45.net
>>78
基本的には依存しない。Makefile.amの内容によっては依存する。
80:あぼーん
あぼーん.net
あぼーん
81:名無しさん＠お腹いっぱい。
03/05/30 15:01.net
>>73
バッドノウハウと「奥が深い症候群」か。
URLﾘﾝｸ(namazu.org)
こんな単純な問題じゃないと思うけどな。autotoolsがバッドノウハウの塊なのは認めるけど。でも、バッドノウハウがなくなることはないと思うよ、漏れは。
82:あぼーん
あぼーん.net
あぼーん
83:あぼーん
あぼーん.net
あぼーん
84:81
03/05/30 15:50.net
>>67
ん?
-- unyalibのMakefile.am ------
SUBDIRS = subDirA subDirB
noinst_LIBRARIES = libunyalib.a
libunyalib_a_SOURCES = unya.c honya.c
libunyalib_a_LIBADD = libsubdir_a.a ...
-- subDirAのMakefile.am ----
noinst_LIBRARIES = libsubdir_a.a
libsubdir_a_a_SOURCES = unya_a.c honya_a.c
でいいんじゃないの? 手元で試してないから嘘言ってるかもしれないけど。
85:81=84
03/05/30 15:54.net
間違えた。
libunyalib_a_LIBADD = libsubdir_a.a ...
は
libunyalib_a_LIBADD = subdirA/libsubdir_a.a ...
ね。
86:名無しさん＠お腹いっぱい。
03/06/05 21:26.net
auto* っつーもんは、backward compatibility を放棄した糞ということでよろしいか？
87:名無しさん＠お腹いっぱい。
03/06/06 13:26.net
Autotools で生成したものの再配布は GNU ライセンスに準じるの？
88:名無しさん＠お腹いっぱい。
03/06/06 21:30.net
>>87
準じないけど、Automakeで配布されるファイルには
いろんなライセンスがあっはず。
バイナリ配るんなら問題無かったと思う。
>>86
糞かどうかは知らんが、同意したい気分だね。
89:名無しさん＠お腹いっぱい。
03/06/06 22:25.net
まあ、こいつの登場で便利になっている事実は否定できないので、
backward compatibility を確保して欲しかったということだけかな。
90:名無しさん＠お腹いっぱい。
03/07/14 03:42.net
backward compatibilityを維持したらどんな事態になるか分るだろ。
91:名無しさん＠お腹いっぱい。
03/07/14 04:11.net
∧＿∧∩ ／￣￣￣￣￣￣￣￣￣￣￣
（ ´∀｀）/＜ 先生！わかりません！！
＿ / / / ＼＿＿＿＿＿＿＿＿＿＿＿
＼⊂ノ￣￣￣￣＼
||＼ ＼
||＼||￣￣￣￣￣||
|| ||￣￣￣￣￣||
.|| ||
92:あぼーん
あぼーん.net
あぼーん
93:名無しさん＠お腹いっぱい。
03/09/14 20:07.net
Automake-1.7.7のconfigureがAutoconf-2.57だと通らず、
Autoconf-2.54だと通る。
config.logは以下の通り（一部抜粋Autoconf-2.57のとき）。
configure:1724: cd conftest && eval autoconf -o /dev/null conftest.ac
autom4te: no such file or directory: m4sugar/m4sugar.m4
configure:1727: $? = 1
configure:1731: error: Autoconf 2.54 or better is required.
Is it installed? Is it in your PATH? (try running `autoconf --version')
Is it working? See also config.log for error messages before this one.
なんか情報ありませんか？
94:名無しさん＠お腹いっぱい。
03/09/14 20:53.net
お騒がせしました。ありました。
URLﾘﾝｸ(mail.gnu.org)
以下のスレッドでした。でもちょっと違うんだよね。困った。
95:名無しさん＠お腹いっぱい。
03/11/20 19:40.net
犬板にあったので
URLﾘﾝｸ(japan.linux.com)
個人的にはconfigure時にはbuildなどディレクトリを掘って
../configureのほうが好み。
96:名無しさん＠お腹いっぱい。
03/11/22 09:20.net
>>95
distclean できる *はず* なので、正直どうでもいい。
97:名無しさん＠お腹いっぱい。
03/11/22 18:24.net
確かにdistcleanできる *はず* ですね。
個人で開発に利用するときは、cleanすら使うことが少ないから、
良く理解していなかった。
98:名無しさん＠お腹いっぱい。
03/12/27 14:58.net
./configureしたときのデフォルトの$prefixが/usr/localなのが不便なので、configure.ac
やMakefile.acの中で--prefix=/usrの指定をできないでしょうか？
99:名無しさん＠お腹いっぱい。
03/12/27 16:19.net
>>98
AC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。
しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの
ではないと思うが。
100:名無しさん＠お腹いっぱい。
03/12/27 16:47.net
Makefile.ac
101:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
03/12/27 18:11.net
>>102
/usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと
ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。
/usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。
Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い
(衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って
そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。
105:名無しさん＠お腹いっぱい。
03/12/27 19:12.net
OSの一部として配布されるもの以外は/usrに入れないのが当り前です。
システム上重要というだけでなく、そのOSを使っている人の間で構成が
一致しているからでもある。
Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ
うのも納得できる。
>>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。
106:名無しさん＠お腹いっぱい。
03/12/27 19:44.net
寄せ集めっつーか、大多数のLinuxディストリにはbase systemと
いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール
したらそれもbase systemの一部だ」みたいなノリなんだろうね。
107:ヽ(´ー`)ノ
03/12/27 20:30.net
>>105
Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。
最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。
特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。
> Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
これは、もはや昔話だよもん。
108:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
04/02/01 23:53.net
古いlibtool使うしかないのでは？
113:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
04/02/04 12:01.net
外してたら済まんが、ac_cvなんとかでスキップできんの?
116:名無しさん＠お腹いっぱい。
04/02/04 14:03.net
たかだか AC_LIBTOOL_SYS_MAX_CMD_LEN のチェックぐらいで数分もかかる
プラットホームは俺の中で問題外なんだけどなｗ
何のために libtool 使ってんのか分からんよ。
117:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
04/02/04 20:02.net
autoconfのドキュメント読んでたら、
$ ./configure --lt_cv_sys_max_cmd_len=4096
でいけるかもしれんような気がした。
しかし、試せない。。。
119:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
04/03/04 19:55.net
すぐ上でされてるみたいだけど、とりあえずやってみれば？
問題があれば誘導されるでしょ。
122:名無しさん＠お腹いっぱい。
04/03/04 20:01.net
configureのコストが、高機能になればなるほどデカクなってきてる
わけですが、これらを動的にチェックするんじゃなくて静的にデータ
ベースのようなもので持たせることはできないですかね。とはいっても
何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう
わけでなかなか難しいんだろうけど。
123:名無しさん＠お腹いっぱい。
04/03/04 20:07.net
>>122
そのためにはconfig.siteを使えばいいと思うんだけど。
124:120
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(続き)
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:名無しさん＠お腹いっぱい。
04/03/04 22:03.net
pkg-configか？と脊髄反射してみる
127:名無しさん＠お腹いっぱい。
04/03/04 22:09.net
>>125
二つのconfigure.acを見比べると、
URLﾘﾝｸ(www.lunar-linux.org)
では
dnl Check for required packages
BM_DEPEND([GTK], [gtk+-2.0], [2.0.6])
BM_DEPEND([LIBXFCE4UTIL], [libxfce4util-1.0], [4.1.6])
になっていて、
URLﾘﾝｸ(www.lunar-linux.org)
では
dnl Check for dependancies
BM_DEPEND([LIBXFCE4UTIL], [libxfce4util-1.0], [4.0.0])
になっているので、違うものがリンクされる可能性はありますが、
それならguiのほうが新しい方を選択しそうですよね。
偉そうに書いておきながら、よく分からんです。
識者の降臨をお待ちします。
128:120
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
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
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:保守
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:名無しさん＠お腹いっぱい。
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
04/08/16 13:35.net
>>134
キモはAM_CONDITIONALとifの組み合わせだったのですね。
やりたいことが実現できてすっきりです。ありがとうございます。
136:名無しさん＠お腹いっぱい。
04/10/08 13:12:44.net
あるプログラムは C、あるプログラムは シェルスクリプト、あるプログラムは Perl を使って書かれた
パッケージを autoconf, automake でインスコさせたい時、
シェルスクリプトとか Perl に関する指示はどう出せばいいんですか?
137:名無しさん＠お腹いっぱい。
04/10/08 13:26:04.net
Makefile.amに
bin_SCRIPTS = fugafufu.pl
とか？
138:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
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:名無しさん＠お腹いっぱい。
05/05/05 14:20:02 .net
143:名無しさん＠お腹いっぱい。
05/05/07 09:54:27 .net
-lhogeでstatic-linkさせる方法を教えて下さい。
144:名無しさん＠お腹いっぱい。
05/05/07 12:38:59 .net
>>143
自作のライブラリなら，
hoge_LDFLAGS = -static
をMakefile.amに追加するのかな？
make時なら，./configure --helpして
それなりのオプションがあれば可能だと思う．
145:名無しさん＠お腹いっぱい。
05/05/07 23:00:52 .net
ありがとうございました
146:名無しさん＠お腹いっぱい。
05/05/08 14:02:17 .net
共有ライブラリのバージョンが違っても動くプログラムを作る方法を教えて下さい
147:名無しさん＠お腹いっぱい。
05/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:名無しさん＠お腹いっぱい。
05/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
05/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:名無しさん＠お腹いっぱい。
05/05/10 00:16:22 .net
>>149
あまりお役に立てなかったようで、、、
後は、ソースからビルドされたようなので、
libtoolのmakeに失敗している可能性もあるので、
libtoolをmakeしたディレクトリでmake checkして、
問題が無いか確認するぐらいかな？
151:名無しさん＠お腹いっぱい。
05/05/12 00:45:45 .net
↓の書き込みも漏れだったりするけど、多分これだと思う。
540 名前：名無しさん＠お腹いっぱい。：05/02/05 01:29:46
>539
そもそも X 自体入れてないんでどうなんか知らんが。
作らないんじゃなくて、作るけどわざわざ入れないようだ。
devel/libtool15 にわざわざ .la をインストールしないようパッチがされてる。
参考: URLﾘﾝｸ(www.freebsd.org)
とりあえず x11/libxfce4/Makefile で
-USE_LIBTOOL_VER=15
+USE_INC_LIBTOOL_VER=15
してやれば .la も入るみたいだけど？
152:名無しさん＠お腹いっぱい。
05/05/12 00:46:58 .net
>151
あー、ごめん早とちりしたかも。
153:名無しさん＠お腹いっぱい。
05/05/25 21:12:32 .net
URLﾘﾝｸ(www-src.lip6.fr)
英語だけどわかりやすい
154:名無しさん＠お腹いっぱい。
05/06/23 12:44:19 .net
autopoint で i18n 化した場合って、GPL 互換のライセンスにしないと駄目なの？
intl/ の下に出来るファイルは全部 GPL だよね？
ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。
155:名無しさん＠お腹いっぱい。
05/06/23 18:12:59 .net
>>154
info gettextのDiscussionsの
* Dependencies over the GPL or LGPL
に[The simplest answer is "normally not".]と書かれている。
一応、読んでみてね。
156:名無しさん＠お腹いっぱい。
05/06/23 18:32:19 .net
>>155
thx。でも英語が分からん…＿|￣|○
一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも
配布できるという解釈で OK?
157:名無しさん＠お腹いっぱい。
05/06/23 20:25:51 .net
>>156
日本語訳
URLﾘﾝｸ(ring.atr.jp)
やっぱりよくわからんけど、そんな感じだと思うけどね。
158:名無しさん＠お腹いっぱい。
05/06/24 01:56:18 .net
よくわからんが、intlの下ってlibintlに入るものと同じなんでしょ?
削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの?
159:名無しさん＠お腹いっぱい。
05/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:名無しさん＠お腹いっぱい。
05/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:名無しさん＠お腹いっぱい。
05/10/18 15:51:25 .net
>>159
subB1.oをリンクし忘れてるとか
リンクの際に引きわたす.oの順番を変えてみるとか
162:名無しさん＠お腹いっぱい。
05/10/18 16:31:26 .net
Makefile.am での”xxx_LIBRARIES =, xxx_SOURCES =”や
configure.in での”AC_CONFIG_FILES()”以外に、
リンク先の指定方法があるのでしょうか？？
なんとなく、各 Makefile.am でリンク先の指定とか
できそうに思うのですが、調べても判りません orz。
163:名無しさん＠お腹いっぱい。
05/10/20 22:59:06 .net
>>159
なんでそんな不思議な事を…
programBのツリー内でlibprogramB.aでも作ればいいんじゃない
164:名無しさん＠お腹いっぱい。
05/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:名無しさん＠お腹いっぱい。
05/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:名無しさん＠お腹いっぱい。
05/10/22 09:40:24 .net
>>164
共通部分はライブラリにしてしまうのがいいと思うのだが、
後、SOURCESなどでは相対パスではなく、$(top_srcdir)
などを利用するのが、最近の流儀です。
# configureを任意のディレクトリで実行可能にするため。
また、SUBDIRSがサブディレクトリではないのも問題になるかも
しれません。
パッケージ構成を再検討したほうがいいと言うのに私も賛成。
167:名無しさん＠お腹いっぱい。
05/10/22 20:26:11 .net
自己解決しました。
*.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで
なかったのが原因のようですた。これで make が通るようになり pgA が
出来上がったのですが、いまいち腑に落ちないです。なんかちょっと
書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。
まあ、自分が悪いのですが。 お答えいただいた皆さんありがとう
ございました。
168:名無しさん＠お腹いっぱい。
06/03/27 13:22:52 .net
URLﾘﾝｸ(www.ossp.org)
これなんですけど、LIBS って環境変数を設定してたら、configure に失敗します。
メインの configure で LIBS を自分用にライブラリ追加して設定してるんだけど、
サブの configure にLIBSが環境変数だから引き継がれて悪影響が出てる。
これって、どれ？
1. LIBS を環境変数として指定するのは間違い
2. メインの configure.ac の書き方がまずい
3. autoconf なんてそんなもの
169:名無しさん＠お腹いっぱい。
06/03/27 21:49:45 .net
>>168
LIBSをunsetしてから
LIBS=hoge ./conifgure
とすると、サブのconfigureに引き継がれないという噂が
利用できるかもしれないが、そうでなければ、
> 1. LIBS を環境変数として指定するのは間違い
かな？
> 3. autoconf なんてそんなもの
これの気もするが、、、
170:名無しさん＠お腹いっぱい。
06/03/28 17:34:44 .net
> LIBS=hoge ./conifgure
だめみたい。
うーん、configure.ac で
LIBS="$LIBS_EXTRA $LIBS"
するのを止めて、Makefile.in で、
LIBS = @LIBS_EXTRA@ @LIBS@
しないとだめなのかなぁ。
ぶー、ぶさいく。
171:名無しさん＠お腹いっぱい。
06/03/32 13:15:03 .net
./configure LIBS=hoge
172:名無しさん＠お腹いっぱい。
06/03/32 15:03:08 .net
ちらしの裏に書いて置くべきことなは、
承知のうえで、あえて、誰かに聞いてもらいたい。
Autoconf,Automake,libtoolのおかげで、コンパイル、インストール
は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ
って思うときに、なんかわけわからなくて。
makefileを自作してたりする。んでそれが面倒なんでソース弄るのも
おっくうになってたり。
みんなはどうしてるの？
173:名無しさん＠お腹いっぱい。
06/03/32 15:15:07 .net
自分で書くCソースはそもそもそんなに複雑じゃないので、
autoconfを使わなくてもMakefileはOSに依存せず、
異なるOS間でも共通(同一)になることが多い。
なので、Makefileを自分で直接書いてる。
もしくは、もっと簡単なソースだとMakefileすら要らず、
makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。
174:名無しさん＠お腹いっぱい。
06/03/32 17:58:32 .net
>>172
使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ
ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん
とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので
それを自動化したprepare_projectなるスクリプトを書いて使ってる
175:名無しさん＠お腹いっぱい。
06/04/02 06:43:54 .net
autoconfは便利だしとっつきやすいが、
automakeまで手を伸ばすのはちと面倒なんだよな。
どうせ最初から使う必要なんてないんだから、
必要を感じてきたらそのとき導入すればいいよ。
>> prepare_projectなるスクリプト
MS的にいうとautotools_wizardだね
176:名無しさん＠お腹いっぱい。
06/04/02 12:22:16 .net
>>171
なるほど。これいけるね。
177:名無しさん＠お腹いっぱい。
06/04/03 03:18:57 .net
>>175
autoconf単独よりautomakeとセットで使う方が断然らくちんだべや
178:名無しさん＠お腹いっぱい。
06/04/07 23:19:18 .net
NFS上でaclocal等を実行すると、perlがflock使っているところで
止まるんだけど、これってperlを-Ud_flock付きでコンパイルする
以外に方法はないのでしょうか？ (aclocalは1.9.6)
179:名無しさん＠お腹いっぱい。
06/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:名無しさん＠お腹いっぱい。
06/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
06/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:名無しさん＠お腹いっぱい。
06/07/20 20:39:59 .net
autoconf-archive
URLﾘﾝｸ(autoconf-archive.cryp.to)
を見ていると、マクロの先頭が、AC,ACX,AXなどいくつかありますが、
それぞれどのような違いがあってつけられているのでしょうか。
183:名無しさん＠お腹いっぱい。
06/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:名無しさん＠お腹いっぱい。
06/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:名無しさん＠お腹いっぱい。
06/11/24 06:20:37 .net
AC_DEFINE_UNQUOTED
186:名無しさん＠お腹いっぱい。
06/11/24 06:35:43 .net
今も聞こえる オウトマケの唄
187:名無しさん＠お腹いっぱい。
06/11/25 03:01:50 .net
>>185
変更したら解決できました。
ありがとうございます。
188:名無しさん＠お腹いっぱい。
06/12/03 05:15:59 .net
AC_CHECK_LIBに/usr/local/libなどのディレクトリも見てもらうようにするには
どうしたらいいんでしょうか？
189:名無しさん＠お腹いっぱい。
06/12/08 09:17:54 .net
そもそも、
AC_CHECK_HEADERSがヘッダを探すサーチパス、
AC_CHECK_LIBがライブラリを探すサーチパス、
は、
どこで定義されていて、
どうやったらそこに任意のディレクトリを追加できるのでしょう？
ドキュメントには記述が発見できず...
190:名無しさん＠お腹いっぱい。
06/12/08 14:19:02 .net
apacheやqmailみたいに１パッケージに複数のアプリケーションが含まれているようなソースツリーの場合にいい感じにconfigureを量産してくれるようなautotoolsが欲しい。
191:名無しさん＠お腹いっぱい。
06/12/08 20:42:36 .net
/usr/share/autoconf とかその辺にあるよ
192:名無しさん＠お腹いっぱい。
06/12/09 22:48:56 .net
>>191
ありがとうございます。
/usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。
/usr/share を変更できない権限で configure 実行時にサーチパスを追加
する方法を探しています。
環境変数INCLUDEにセットしてみたり、
./configure INCLUDE=hoge
とかやってみているのですが、うまくいかずです。
193:名無しさん＠お腹いっぱい。
06/12/13 15:01:54 .net
./src
main.c
./others
hoo.h
という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am
はどのように書けばいいのでしょうか？
194:名無しさん＠お腹いっぱい。
06/12/13 15:03:01 .net
すいません書き忘れです。
./others
hoo.h
hoo.c
という感じです
195:名無しさん＠お腹いっぱい。
06/12/14 04:27:56 .net
>>192
環境変数で解決しました。
AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、
AC_CHECK_LIB は LIBS=-L<lib_dir>
で設定したディレクトリを探してくれるようです。
196:手元にある本から・・・
06/12/16 18:51:20 .net
>193
GNU Autoconf/Automake/Libtool
URLﾘﾝｸ(www.amazon.co.jp)
P48 6.5:よくある質問 から引用
ライブラリのソースが複数のサブディレクトリにあるとき、どうmakeしたらよいでしょうか？
ライブラリではほとんどの場合、libtoolコンビニエンスライブラリを使うことで簡単に解決できます。
しかし、プログラムについては簡単な解決策がなく、パッケージの構造の変更を選ぶ人が少なく有りません。
Automakeの次期メジャーリリースでは、この問題に進展があるはずです。
最新verならできるのかな？この本が翻訳された段階(平成13年)ではまだ無理っぽいみたいだし
197:名無しさん＠お腹いっぱい。
06/12/16 19:59:25 .net
>>196
ありがとうございます
どうにも良く分からないので
./src
main.c
./others
hoo.h
hoo.cpp
を、libothers.aとライブラリにして、./srcでリンクさせてます。（リンクが成功しないんですがこれは別問題かと）
うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか
198:名無しさん＠お腹いっぱい。
06/12/16 20:55:20 .net
>>196,197
今試したら少なくともautomake-1.9.5だと
うまくサブディレクトリを扱えるみたい
199:名無しさん＠お腹いっぱい。
06/12/17 04:04:49 .net
具体的な書き方が分からないのですが、教えていただけませんか？
200:名無しさん＠お腹いっぱい。
06/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
06/12/17 18:48:32 .net
>>199
具体的もなにもmain.cのあるディレクトリのMakefile.amで
hoge_SOURCES=main.c others/hoo.h others/hoo.cpp
するだけだよ
othersにあるファイルも同じように扱えるようになったみたいなので
わざわざライブラリにまとめる必要はない
202:名無しさん＠お腹いっぱい。
06/12/17 23:34:00 .net
>>200 >>201
ありがとうございます。
確かにmainのあるディレクトリでothers/hoge.cppと指定すれば出来ました。
しかし、サブディレクトリに物凄くファイルがあるので、階層別にMakefileを作り、ライブラリにしたほうが管理しやすそうに思えます。
あと、>>200さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか？
それともnoinst_LIBRARIESにした方がいいのでしょうか？
203:名無しさん＠お腹いっぱい。
06/12/18 17:47:27 .net
>>202
> あと、>>200さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか？
> それともnoinst_LIBRARIESにした方がいいのでしょうか？
ほかで利用するならインストールするけど、そうでなければ
デフォルトでstaticにしないと不味いかもしれません。
他で使うなら、include_HEADERSにヘッダを書かなきゃだめですが、、、
判断できない場合は、とりあえずインストールするのが無難です。
# libhoo.laはデバッグ時に必要です。
204:名無しさん＠お腹いっぱい。
06/12/18 21:31:01 .net
> libhoo.laはデバッグ時に必要です。
*.laって何するものなの?
205:名無しさん＠お腹いっぱい。
06/12/18 23:43:10 .net
>>204
> *.laって何するものなの?
$ libtool gdb hogehoge
ってやるとき、参照するライブラリが書かれているテキストファイルだと
思っているのですが、、、
識者の方ツッコミよろ。
206:名無しさん＠お腹いっぱい。
06/12/24 20:13:53 .net
noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。
207:名無しさん＠お腹いっぱい。
07/06/23 21:05:43 .net
AC_CHECK_HEADERなどで宣言されるHAVE_*の先頭に識別子をつけることはできる？
#define HOGE_HAVE_MEMORY_H
となるような。
hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが
ライブラリを使う側にHAVE_*が影響してしまうので
ライブラリのコンパイル後に消すか、名前を変えるかしたい。
しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので
単純にconfigヘッダーをインストールしないというわけにもいかず。
208:名無しさん＠お腹いっぱい。
07/06/24 05:32:53 .net
>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_* の状態が違っているなら正常動作しなくても当然なんじゃない？
209:名無しさん＠お腹いっぱい。
07/06/24 12:30:43 .net
ライブラリのヘッダでconfig.hを読むってのが変だと思うけどなあ。
210:名無しさん＠お腹いっぱい。
07/06/24 22:52:30 .net
>>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の意味が無いというか。
普通どうやるんでしょ？
211:名無しさん＠お腹いっぱい。
07/06/24 23:10:23 .net
>>208
>ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない？
動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。
Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。
212:名無しさん＠お腹いっぱい。
07/06/25 00:46:53 .net
不要なものをhoge_config.h.inから削除するとhoge_config.hに反映されないことに気づきました。
213:名無しさん＠お腹いっぱい。
07/06/25 17:54:39 .net
>>210
ライブラリのヘッダファイルであるかどうかわからないtypedefをさらにtypedefって
あまり見ないような。大抵自分で型を判断してやってないか。
214:名無しさん＠お腹いっぱい。
07/06/25 23:28:01 .net
>>213
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか？
215:名無しさん＠お腹いっぱい。
07/06/26 18:44:44 .net
>>214
そのライブラリを使うアプリのconfigureでやればいいんでない？
そういう話では無いのかな
216:名無しさん＠お腹いっぱい。
07/07/07 22:49:39 .net
>215
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
しておけば OK かな。
217:名無しさん＠お腹いっぱい。
07/07/08 20:43:24 .net
>>216
うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。
hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。
結構面倒な作業になるのかもしれないけど、、、
まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、
どっちが良いかはよく分からないです。
218:名無しさん＠お腹いっぱい。
07/07/23 03:24:18 .net
CFLAGSとCPPFLAGSの違いがよくわかりません
Cプリプロセッサフラグってどういうことでしょうか？
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。
219:名無しさん＠お腹いっぱい。
07/07/23 11:01:31 .net
なぜそこで
> Cプリプロセッサフラグ
という自分の推測が間違っているということを疑わないのか。
220:名無しさん＠お腹いっぱい。
07/07/23 19:01:58 .net
いや、推測じゃないです。
URLﾘﾝｸ(sources.redhat.com)
で
CPPFLAGS
C/C++ preprocessor flags
となってます。
221:名無しさん＠お腹いっぱい。
07/07/23 21:04:35 .net
まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな？
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ？
222:名無しさん＠お腹いっぱい。
07/07/23 22:30:52 .net
>>221
いや、これ、infoのhtml版だから、ほぼ正式と思っていいと思う。
>>218
URLﾘﾝｸ(sources.redhat.com)
CXXFLAGSがC++のときのCFLAGSみたいなもの
プリプロセッサとは、
URLﾘﾝｸ(e-words.jp)
これでも読んでくれ。#includeを処理するのが何か分かれば
多分理解できると思う。
223:名無しさん＠お腹いっぱい。
07/07/23 23:56:05 .net
ありがとうございます。
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした
224:名無しさん＠お腹いっぱい。
07/07/24 23:43:52 .net
まず問いたい。
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか？w
225:名無しさん＠お腹いっぱい。
07/11/28 22:49:28 .net
bin_PROGRAMS=/tmp/fuga
とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか？
226:名無しさん＠お腹いっぱい。
07/11/29 08:39:52 .net
できるかどうかわからないけど、なぜそういうことをしたいのか
の目的がわかれば、別の解決法が出てくるかもね。
227:名無しさん＠お腹いっぱい。
07/11/29 11:49:47 .net
自分のホームディレクトリにソースがあったとしても、
/tmp/でmakeしたいんです。
/home/my/src/"ここにソースがある"
けど、makeを叩くことで、
/tmp/でビルドさせたいんです。
228:名無しさん＠お腹いっぱい。
07/11/29 19:43:54 .net
>>227
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。
/tmp で/home/my/src/configure
すれば、/tmp以下にMakefileができると思うけど。
そういう話ではない？
229:名無しさん＠お腹いっぱい。
07/11/29 23:14:50 .net
Makefileの中身が相対パスで書かれてるみたいなので、
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね？
230:名無しさん＠お腹いっぱい。
07/11/30 09:52:32 .net
それは多分そのプログラムの方が悪い(autotoolsの使い方の問題)。
tmpに全部コピーした方が早そう。
231:名無しさん＠お腹いっぱい。
07/12/01 02:00:10 .net
普通、相対パスで書かないものですか？
232:名無しさん＠お腹いっぱい。
07/12/01 09:41:28 .net
>>231
srcdir や top_srcdir への相対パスなら大丈夫だけど、
# 絶対パスならabsを付ける
カレントディレクトリからのパスになってるんじゃない？
233:名無しさん＠お腹いっぱい。
07/12/18 17:33:38 .net
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
を見に行ってしまいエラーになってしまいます。
回避する方法ってありますか？
234:名無しさん＠お腹いっぱい。
07/12/18 23:29:27 .net
>233
my_src_dir=/home/xxx/src
prog_SOURCES=$(my_src_dir)/test.c
だったら通ったりしない？
って絶対パスじゃないと駄目なの？そーいうのはソースじゃなくてライブラリにしないか？
235:名無しさん＠お腹いっぱい。
07/12/19 20:40:41 .net
あちこちにあるファイルを集めて一つのディレクトリツリーを作りたいんですが、
なんかうまいやりかたは無いんでしょうか
a/b/c/hoge : d/e/hoge
install ...
a/b/c/huga : f/g/huga
...
とか延々と書くのが面倒臭いんです...
236:名無しさん＠お腹いっぱい。
07/12/23 11:19:48 .net
>>234
ダメなんです。なぜかそういう風に展開されちゃうんですよね・・・
237:sage
08/11/15 00:31:39 .net
同じソースファイルを使って、実行ファイルと共有ライブラリを
作りたいのですが、
‘created with both libtool and without’エラーが吐かれて、
うまくいきません。
URLﾘﾝｸ(www.gnu.org)
の8.3.9.2 Objects ‘created with both libtool and without’
に解決らしき記述があるのですが、意味がわからず困っています。
どうしろと書いてあるのでしょうか？
238:名無しさん＠お腹いっぱい。
08/11/15 11:13:40 .net
>>237
そこの
> A workaround for this issue is
以下をていねいに読めばだいたいわからんかな？
prog_CFLAGS = $(AM_CFLAGS)
を追加して、副作用として prog.c と foo.c が prog-prog.o と prog-foo.o に
コンパイルされるようにする（そうすることで、ライブラリのほうの
オブジェクトファイルと、名前がぶつからないようにする）、とある。
239:名無しさん＠お腹いっぱい。
09/06/28 12:09:38 .net
linuxなんですがAutoconf,Automakeについて質問してもいいですか？
240:名無しさん＠お腹いっぱい。
09/08/10 13:58:44 .net
どうぞ
241:名無しさん＠お腹いっぱい。
11/04/12 05:29:50.46 .net
hoyu
242:名無しさん＠お腹いっぱい。
12/10/19 00:16:16.94 .net
URLﾘﾝｸ(shop.oreilly.com)
良いか？
243:名無しさん＠お腹いっぱい。
14/04/07 01:55:27.82 .net
llvm bitcodeを中間コードとしてビルドするようなmakefileをautotoolsで作れませんかね？
244:名無しさん＠お腹いっぱい。
15/01/03 09:15:56.58 .net
--with-* と --enable-* との使い分け方が解らない。
URLﾘﾝｸ(www.geocities.co.jp)
を読んでも解らない。
どっちを使っても良いのかな?
245:名無しさん＠お腹いっぱい。
15/01/03 21:25:10.13 .net
ぐぐったら入力途中で候補にautoconf with vs enableというのが出てきたので
その結果を見てみたらいろいろと議論はあるようだ。
URLﾘﾝｸ(mail.python.org)
ここの解説だと、機能の有無を決めるのにenable、依存するパッケージとかの
指定にwithを使うという感じみたい。それでも例外もあるようだ。
246:名無しさん＠お腹いっぱい。
15/01/03 23:36:29.26 .net
>>245
構文はそっくりだけど意味は違うよ、適切に使い分けてね
って事かな…?
今回はpackageの有無で機能を切り替えるので--with-*を使うことにするわ、サンクス!
247:名無しさん＠お腹いっぱい。
15/01/04 00:09:09.26 .net
英語の意味通りですな
248:名無しさん＠お腹いっぱい。
15/01/06 19:37:27.79 .net
キター!
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:
fURLﾘﾝｸ(ftp.gnu.org)
fURLﾘﾝｸ(ftp.gnu.org)
249:名無しさん＠お腹いっぱい。
17/06/25 07:39:08.66 .net
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.
250:名無しさん＠お腹いっぱい。
17/12/29 07:37:16.28 .net
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
CAEY39R21B
251:名無しさん＠お腹いっぱい。
18/05/22 06:13:54.01 .net
知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
CGFTL
252:名無しさん＠お腹いっぱい。
20/03/22 17:23:39.15 .net
過疎化してますね、このスレ.
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: <URLﾘﾝｸ(lists.gnu.org)
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.
253:名無しさん＠お腹いっぱい。
20/11/22 07:21:08.96 .net
このスレ見てる人いるんだろうか?
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: <URLﾘﾝｸ(lists.gnu.org)
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!
254:名無しさん＠お腹いっぱい。
20/12/30 10:59:12.06 .net
誰も気にしてないと思うが、今月autoconfが新しくなった。
URLﾘﾝｸ(lists.gnu.org)
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:
URLﾘﾝｸ(savannah.gnu.org)
Please also send general comments and feedback to <autoconf@gnu.org>.
255:名無しさん＠お腹いっぱい。
21/08/29 23:18:19.04 .net
もはや追いかける者もいなくなったか。
URLﾘﾝｸ(lists.gnu.org)
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:
URLﾘﾝｸ(ftpmirror.gnu.org) (2.0MB)
URLﾘﾝｸ(ftpmirror.gnu.org) (1.3MB)
Here are the GPG detached signatures[*]:
URLﾘﾝｸ(ftpmirror.gnu.org)
URLﾘﾝｸ(ftpmirror.gnu.org)
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.
256:名無しさん＠お腹いっぱい。
21/08/29 23:24:29.22 .net
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
257:名無しさん＠お腹いっぱい。
21/08/29 23:40:02.72 .net
人手が足りていないらしい。
URLﾘﾝｸ(www.gnu.org)
New volunteers to help maintain Automake are needed. Please help if you can.
URLﾘﾝｸ(lists.gnu.org)
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:
URLﾘﾝｸ(debbugs.gnu.org)
258:名無しさん＠お腹いっぱい。
22/02/25 12:58:42.23 .net
Autoconf,Automake
259:名無しさん＠お腹いっぱい。
24/03/27 20:18:27.93 .net
彼女←隠すならぜんぜんいい
マネージャーはクビだろうな
じゃキンプリはないんじゃないかな
260:名無しさん＠お腹いっぱい。
24/03/27 21:02:56.80 .net
実質賃金だけでも
ニコ生は中抜きがえげつない
そんなん言ってスクエニ辞めて
261:名無しさん＠お腹いっぱい。
24/03/27 21:51:16.15 .net
戦争がしたいなら脱退してくれ
みんなでオッパの帰りを祈りましょう🙏❤
貧乏なのでぇNISA枠でデイトレすればいいのに
262:名無しさん＠お腹いっぱい。
24/04/19 20:05:37.16 .net
xzの穴にautoconfの難読度が利用されてしまいましたなあ
263:名無しさん＠お腹いっぱい。
25/02/21 15:33:38.62 uEwwaGSO9
民間航空騷音集団訴訟が始まってるが、騒音に繋がるものは全部反対して徹底攻撃，航空機を阻害するものは全部擁護の姿勢が大切な
反対］全航空機、全公務員、少孑化対策、自閉隊、米軍駐留．日米同盟、観光文化芸術等への支援、スポーツ、万博、自民公明．銃刀法
賛成)人口減少、遷都、日本列島縦断クソ航空機姦国との国交断絶．航空機撃墜、金正恩のミサイ儿、習近平の気球、環境活動家の破壊活動
世界最悪の殺人組織公明党國土破壊省の強盗殺人の首魁斉藤鉄夫らテロリストに乗っ取られたクソ政府が、力による一方的な現状変更によって
鉄道のЗ0倍以上非効率なクソ航空機飛は゛しまくって莫大な温室効果ガスまき散らして気候変動、日本どころか世界中で災害連発させて大量
殺戮することで私腹を肥やす強盗殺人を繰り返しているわけだが、悪の権化みたいなこいつらか゛ロシア非難とか寝言は寝て言えって話た゛よな
石油無駄に燃やしてエネ価格から物価にと暴騰させて騒音で住民の生活に仕事にと破壊して憲法13条25条29条と違反しまくってる悪質
テ囗リスト航空関係者個人を迫害したり，バ力チョンをバ力にして差別したり、ルフィやプーチンを擁護したり．て゛きることは何でもやろう!
(ref.) ΤΤps://www.call4.jp/info.php?type＝iＴems&id=I0000062
ttｐs：//haneda-ＰrojеcТ.jimdofree.ｃom/ , ttρs:/／flight-route.Ｃom/
URLﾘﾝｸ(n-souonhigaisosyoudan.amebaownd.com)