0001名無しさん＠お腹いっぱい。
NGNG関連サイトは>>2
探検
Autoconf,Automakeについて
関連サイトは>>2
0049名無しさん＠お腹いっぱい。
NGNG勉強ってほどのもんでもない。
0050名無しさん＠お腹いっぱい。
NGNG0051山崎渉
NGNG0052あぼーん
NGNG0053名無しさん＠お腹いっぱい。
NGNGありますが、ふつうはどこまで含めるものなんですか。
0054名無しさん＠お腹いっぱい。
NGNGautoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、
古いバージョンも後生大事に用意されていますよね。
これは何故なんでしょうか？
何か後方互換性に大きな問題でもあるのでしょうか？
0055名無しさん＠お腹いっぱい。
NGNG0056名無しさん＠お腹いっぱい。
NGNGなるほど。
そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、
といった判断は一般にどのような基準に基づいて行えば良いのでしょうか？
0057名無しさん＠お腹いっぱい。
NGNG違うバージョンを使うと動かないので悩む必要はありません。
0058名無しさん＠お腹いっぱい。
NGNGう〜ん、やっぱり良くわからないです。
とどのつまり、知りたいのは、
PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、
とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか？
それとも、古いバージョンのも入れておいた方が良いのでしょうか？
0059名無しさん＠お腹いっぱい。
NGNGconfigure.acまでと言いたいが、今のAutotoolsのバージョン間の互換性から、
configureまで入れておいたほうが無難。誰でもcheckoutできるプロジェクト
なら、「autoconfを実行するとエラーが出ます」というレポートが大量発生す
る可能性が高い。しかし、confugure.acやMakefile.amを書き換えると同じ状
況になるんだよね。
AM_INIT_AUTOMAKE([1.7])とかAC_PREREQ(2.57)とか書けばいいのかな？
0060名無しさん＠お腹いっぱい。
NGNGAutotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。
他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが
あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー
スを書いた人が使っているものと同じバージョンがないとうまく動かないこと
もあります。更に、これらのツールは同じprefixにインストールしないとうま
く動かない場合が多いです。
私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、
libtoolだけはいい方法が見つからないです。
0061>>53
NGNGさんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。
すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。
configureはtarballに入れればいいし。
0062名無しさん＠お腹いっぱい。
NGNGどうもです。
私はとくに他人のプロジェクトに参加したりということもなさそうですので、
最新のを入れて問題なさそうですね。
0063名無しさん＠お腹いっぱい。
NGNGAC_SEARCH_LIBS(tputs, ncurses termcap, HAVE_TERMCAPとdefine, ダメです)
みたいなライブラリチェックしかなくてSolaris8上でのconfigureが不能です。
対症療法よりもその辺全面的に書き換えようと思うんで、
configure.in での termcap, curses, ncursesのチェックのお手本になるソフト探してます。
readlineをリンクすることも可能で、Solarisでconfigure;make 可能なソフト、
なんかないでしょうか？gdb?
0064名無しさん＠お腹いっぱい。
NGNGGNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。
infoコマンドのソースはgdbより少ないかな？
006563
NGNG0066名無しさん＠お腹いっぱい。
NGNG事情により初めてautoconf/automake使い始めたとこなんですが、
unyalib--------------------subDirA
ソ ースいくつか | ソースいくつか
|
|
|-----subDirB
ソースいくつか
という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、
なおかつ、そのライブラリの一部になっているサブディレクトリにも
ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、
0067名無しさん＠お腹いっぱい。
NGNG-- 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の実行が挟まれず、一つのライブラリにさせる技は無いでしょうか。
0068あぼーん
NGNG0069名無しさん＠お腹いっぱい。
NGNG一つのライブラリになるわけはない罠。
007067
NGNGautomakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、
一つのディレクトリに集まっているというのしか想定していないということでしょうか。
0071名無しさん＠お腹いっぱい。
NGNG$(topsrcdir)とかで指定するんだったかも。
1.4頃の記憶なんで違うかもしれん。
どっちかというとlibtoolsの話かもしれんけどね。
007267
NGNGSUBDIRS無し、
libunyalib_a_SOURCES = unya.c honya.c subDirA/unya_a.c subDirA/honya_a.c
とかしてみると、
subDirA下のソースに対するオブジェクトがunyalib(ライブラリソースツリーの根っこ)下に
作成されるけど、ライブラリのためのオブジェクトはサブディレクトリから取ってこようとする
Makefileが出来ちゃいまひた。
で、もう、最初のMakefile.inはautomakeで作るけど、
それを手で修正して以後automakeは使わないという決定が
本日なされちゃって、この件は棚上げとあいなりました。
ありがとうございました。
0073名無しさん＠お腹いっぱい。
NGNG使いにくいのを奥深さと勘違いしてるだけだろ。
0074>>53
NGNG奥が深くて使いづらいと申し上げているのです。
0075あぼーん
NGNG0076あぼーん
NGNG0077名無しさん＠お腹いっぱい。
NGNG0078名無しさん＠お腹いっぱい。
NGNG0079名無しさん＠お腹いっぱい。
NGNG基本的には依存しない。Makefile.amの内容によっては依存する。
0080あぼーん
NGNG0081名無しさん＠お腹いっぱい。
NGNGバッドノウハウと「奥が深い症候群」か。
ttp://namazu.org/~satoru/misc/bad-knowhow.html
こんな単純な問題じゃないと思うけどな。autotoolsがバッドノウハウの塊なのは認めるけど。でも、バッドノウハウがなくなることはないと思うよ、漏れは。
0082あぼーん
NGNG0083あぼーん
NGNG008481
NGNGん?
-- 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
でいいんじゃないの? 手元で試してないから嘘言ってるかもしれないけど。
008581=84
NGNGlibunyalib_a_LIBADD = libsubdir_a.a ...
は
libunyalib_a_LIBADD = subdirA/libsubdir_a.a ...
ね。
0086名無しさん＠お腹いっぱい。
NGNG0087名無しさん＠お腹いっぱい。
NGNG0088名無しさん＠お腹いっぱい。
NGNG準じないけど、Automakeで配布されるファイルには
いろんなライセンスがあっはず。
バイナリ配るんなら問題無かったと思う。
>>86
糞かどうかは知らんが、同意したい気分だね。
0089名無しさん＠お腹いっぱい。
NGNGbackward compatibility を確保して欲しかったということだけかな。
0090名無しさん＠お腹いっぱい。
NGNG0091名無しさん＠お腹いっぱい。
NGNG（ ´∀｀）/＜ 先生！わかりません！！
＿ / / / ＼＿＿＿＿＿＿＿＿＿＿＿
＼⊂ノ￣￣￣￣＼
||＼ ＼
||＼||￣￣￣￣￣||
|| ||￣￣￣￣￣||
.|| ||
0092あぼーん
NGNG0093名無しさん＠お腹いっぱい。
NGNGAutoconf-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.
なんか情報ありませんか？
0094名無しさん＠お腹いっぱい。
NGNGhttp://mail.gnu.org/archive/html/automake/2003-07/msg00018.html
以下のスレッドでした。でもちょっと違うんだよね。困った。
0095名無しさん＠お腹いっぱい。
NGNGhttp://japan.linux.com/desktop/03/11/20/0516251.shtml
個人的にはconfigure時にはbuildなどディレクトリを掘って
../configureのほうが好み。
0096名無しさん＠お腹いっぱい。
NGNGdistclean できる *はず* なので、正直どうでもいい。
0097名無しさん＠お腹いっぱい。
NGNG個人で開発に利用するときは、cleanすら使うことが少ないから、
良く理解していなかった。
0098名無しさん＠お腹いっぱい。
NGNGやMakefile.acの中で--prefix=/usrの指定をできないでしょうか？
0099名無しさん＠お腹いっぱい。
NGNGAC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。
しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの
ではないと思うが。
0100名無しさん＠お腹いっぱい。
NGNG0101名無しさん＠お腹いっぱい。
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あたりに何故できないかの情報があるかもしれないので、
ながめてみてください。
レスを投稿する
ニュース
- 【サッカー】EURO前回王者イタリアがベスト16敗退…スイスが2大会連続のベスト8進出決定！ [久太郎★]
- ラーメン店主異例の訴え「食事中にイヤホンやめて」「回転率当然落ちる」強制じゃないがマナー守って★３ [Gecko★]
- 【トヨタ系】下請け５０社に金型を無償で長期保管させる…最大３０年・被害総額は数億円の可能性 [香味焙煎★]
- 【能登は見捨てられた…】能登半島地震から半年…復旧復興はなぜ進まないのか ★2 [ぐれ★]
- 【サッカー】国立競技場、8万人に増席可能とする計画 ピッチサイドに仮設席を設けて増席 [冬月記者★]
- 【👦】「女子トイレや婦人科に男の子を連れて来ないで」“男児ヘイト”に悩む男児ママたち ★2 [ぐれ★]
- ⁺⊹˚.⋆✨(( 👊 ･᷄ὢ･᷅ )🤜VIP巡回中
- すかいぷしよ？
- 酒飲めないって人どうしても疑ってしまう
- 【画像】家にある1番やべぇものあげてけWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
- お前らお金ない辛いお金ないキツい言っているが、生活保護の私の支給額は...😫
- ハッカーのKADOKAWA個人情報公開まであと24時間 [902666507]