5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Autoconf,Automakeについて

1 :名無しさん@お腹いっぱい。:02/04/11 05:24
奥深さの前に使い方がさっぱり分からん。教えて下さい。

関連サイトは>>2

2 :名無しさん@お腹いっぱい。:02/04/11 05:25
GNU Autoconf, Automake and Libtool
http://sources.redhat.com/autobook/

autoconf and automake入門(チュートリアル形式)
http://www.ainet.or.jp/~inoue/gnu/autoconf.html

AUTOCONF, AUTOMAKE を使ってみよう!
http://www.a2zsd.co.jp/~a2zsd217/book/autoconf/book1.html

autoconfとは?(概要図あり)
http://www.i.kyushu-u.ac.jp/~s-mita/autoconf.htm

3 :名無しさん@お腹いっぱい。:02/04/11 05:40
もの凄い勢いで終了したスレはここですか?

4 :名無しさん@お腹いっぱい。:02/04/11 05:49
http://www.ainet.or.jp/~inoue/gnu/whatis.html
> なぜ使うのか
> もちろん、表の理由は、移植性の高いソフトウェアを作ることにありますが、
> 裏の理由として、GNUへの忠誠を示すことができる点があります。

……(´д`;)


5 :3:02/04/13 11:19
本当に終了してる(^_^;)マァヴサゲ


6 :名無しさん@お腹いっぱい。:02/04/13 11:34
configureスクリプトよく見たらsockaddr.sa_lenがあるかどうかとか
チェックしてくれているのね。少し驚いたので、あげ。

7 :デフォルトの名無しさん:02/04/13 12:31
>4
RMSの言う自由ってさ、ブッシュの言うそれと似てる気がする。
ま、彼も所詮「アメリカ」人ってことだーね。

8 :名無しさん@XEmacs:02/04/13 17:51


           ウゼえ消えろ
      ∧_∧          _ _     .'  , .. .∧_∧
     ( ´_ゝ`)   _ .- ― .= ̄  ̄`:, .∴ '     ( >>1 )
    /     '' ̄      __――=', ・,‘ r⌒> _/ /
   / /\   / ̄\-―  ̄ ̄   ̄"'" .   ’ | y'⌒  ⌒i
 _| ̄ ̄ \ /  ヽ \_              |  /  ノ |
 \ ̄ ̄ ̄ ̄ ̄ ̄ \__)              , ー'  /´ヾ_ノ
  ||\            \          / ,  ノ
  ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄          / / /
  ||  || ̄ ̄ ̄ ̄ ̄ ̄ ̄||          / / ,'
  ||  ||           ||       /  /|  |
                       !、_/ /   〉

         ∧_∧   死ね
        _( ´_ゝ`)
      /      )           _     _
     / ,イ 、  ノ/    ∧ ∧―= ̄ `ヽ, _
    / / |   ( 〈 ∵. ・(   〈__ >  ゛ 、_―
   | !  ヽ  ー=- ̄ ̄=_、  (/ , ´ノ
   | |   `iー__=―_ ;, / / /   ←>>1
    !、リ  -=_二__ ̄_=;, / / ,'
        /  /       /  /|  |
       /  /       !、_/ /   〉
     / _/             |_/
     ヽ、_ヽ


   正   直   逝   っ   て   >>1  は   ア   ホ


                          _,-''  )  。゚・   。 。
         ∧ ∧            , -' (.__,-''   ,   , , 。゜
       , - ´_ゝ`)_         .,-'~ ,- '    /  /  i〜i /, 。
      /   )ヽ(w i      .,-'~  ,-'~    // , /// 〜 //,
     .,/  /   ヽヽヽ   ,-/'~  ,ノ      / ////@ @// '/
     / ^)'死  _ l ゝ _)-'~   ,-'~     //, ' ⌒/∨ ̄∨ ⌒ヽ
    / /'  ヽ    ^ ̄   ,-'~       / /     >>1  ヽ ゚ ・
   (iiiiリ∫ ヽ      ./    (⌒`〜〜'  /i  ノ 愛  ノ\ ヽ
       ヽ─|〜' ノ/      ゙〜〜〜〜  |      ./  `- '
        || ||l、_  /          ,,,     |     /  ゚ 。
  |.|  _|.|_,,,|   |        __-'',,-~   /    /
  .|.| ニ─、─''''|   |       =-'''     /   、 ヽ
  .|.|    |.|  .|  |              |    l  l
  |.|    |.|  .|  '、      _     _.|   /  ノ
  .|.|  ,,== ==.|   l      .|.|  ,_,,-'',,,-|  / |  /
   |.| ||_ノノ   |  |      i、`''',,-''''  |  /  .| .|
   .|.レ `-- '    |  |        ̄   | .ノ   | )
         ,- |  |     .....     | .|    ||
         `ヽ   );;;::::::::'''''      | |     | .|
           ゙ - '''''''       ,- 、| | ,,,,,;;;;;;;;と__)''
                      \__);;;;;;;''''''



9 :名無しさん@お腹いっぱい。:02/04/13 21:06
特定のライブラリがユーザによってインストールされているかを
autoconf で調べるのって邪道だと思わない?

10 :名無しさん@お腹いっぱい。:02/04/13 21:38
>>9 ライブラリ作者に.m4ファイルを書けってこと?
そこまでFSFに魂を売り渡したくない人達はどうするよ。
たとえば、X関係とか。



11 :名無しさん@お腹いっぱい。:02/04/13 22:39
Imake最強

12 :名無しさん@お腹いっぱい。:02/04/13 23:19
おめーらんなこというならgcc使うなよ

13 :名無しさん@お腹いっぱい。:02/04/13 23:51
>>12
(゚Д゚)ハァ?

14 :名無しさん@お腹いっぱい。:02/04/14 01:18
なんかこの板最近殺伐としてきたな。喜ぶべきことかどうなんだろうか・・・

15 :名無しさん@お腹いっぱい。:02/04/14 10:33
>11
いつのまにcross buildの機能が付いたね。FreeBSD的には有難い。
しかし、そんなこと知らずに偽cpp作ってゴリゴリhost.defとか書た
苦労はいったい・・・

16 :名無しさん@お腹いっぱい。:02/04/14 11:03
autoconf、automakeのスレ、荒れてる。
もったいないよ、盛り上げようよ。

17 :名無しさん@お腹いっぱい。:02/04/14 11:24
何もわかってない馬鹿が暴れてるんだろうな >>8 >>12

18 :名無しさん@お腹いっぱい。:02/04/14 12:03
configure.inを書かずにGPLで配布することは恥かしいことなんですか?(w

19 :名無しさん@お腹いっぱい。:02/04/14 13:42
>>18 configure.in
configure.acを利用しない方が恥ずかしい罠。


20 :名無しさん@お腹いっぱい。:02/04/14 16:28
どーでもいいけど板違いな気がするんですが


21 :9:02/04/14 19:44
>>10
autoconf は OS 間の非互換性を補う使い方に留めてほしい。
自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE
みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。
そのライブラリを使うか使わないかはユーザが決める事柄なんだから、
--with-libhoge とも --withoug-libhoge とも指定してないのに、勝手に
WITHOUT_HOGE とかして欲しくない。
黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。
事前に親切に「libhoge ねえぞ、入れろやゴルァ」と言ってくれれば便利だが、
そこまでは求めない。

あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include
以外の場所も適宜探してくれないと不便だと思う。何でも /usr 直下に
突っ込むことを暗黙の前提としているのではないか。

22 :10:02/04/14 21:29
了解。勘違いしていた。

>>21
> 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE
> みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。
これは同感です。
# というより、Autoconfの使い方が悪い。

> 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。
これやっちゃうと、バグの報告が大量に発生すると思うので、マトモなパッ
ケージなら、

> 事前に親切に「libhoge ねえぞ、入れろやゴルァ」
と言ってくれると思うんですがどうでしょう。
# マトモの定義の話は無しね。

多分、Makefileを適切に書くのが面倒だから「Automake Autoconfでパッケー
ジ作りました」ってのが多いんだと思う。AC_CHECK_XXXの引数できちんとエラー
処理すれば大丈夫でしょ。

> あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include
> 以外の場所も適宜探してくれないと不便だと思う。

ライブラリについてはリンクを実際に行なって調査するので、ユーザが環境変
数を設定することで何とかなりますし、ヘッダの方もコンパイル可能かどうか
を調査するので同じことではないでしょうか?
ま、言いたいのは、道具はいいけど使い方は人それぞれってことです。

23 :名無しさん@お腹いっぱい。:02/05/07 06:43
age

24 :名無しさん@お腹いっぱい。 :02/05/09 13:38
関係ないんだけど、いいですか?
UNIXの人はWindowsでプログラミングするときは
nmakeとcygwin(gmake)のどっち使ってますか?

nmake使いづらいです。。

25 :名無しさん@お腹いっぱい。:02/05/09 15:02
>>24
nmakeってことはVC++?
だったらmsdev使うけど。

26 :名無しさん@お腹いっぱい。 :02/05/09 15:22
>>25
vs持ってないもんで、、

27 :名無しさん@お腹いっぱい。:02/05/09 17:23
>26
バカヤロウ。ここはUNIX板。
Windowsはcygwinを入れて使うもんだろ。
コンパイラまでgnuを使うわけにはいかないことも
あるが、それ以外は当然全てgnu!

28 :名無しさん@お腹いっぱい。:02/06/14 18:43
Automake 1.6.2 released
sageですが ;-)

29 :名無しさん@お腹いっぱい。:02/07/08 21:37
JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな?
最低限 make と make install と make dist を使えるようにしたいのだけど。

で、
--- Makefile.am ---
bin_PROGRAMS = hello.jar
hello_jar_SOURCES = Main.java

-- configure.in --
AC_INIT(Main.java)
AM_INIT_AUTOMAKE(hello, 1.0.0)
AC_ARG_PROGRAM
AC_PROG_INSTALL
AC_PROG_CC
AC_OUTPUT(Makefile)

とかやってみたけど当前のように正しいMakefileは出来ないし。

30 :名無しさん@お腹いっぱい。:02/07/08 22:40
>>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
>>30
gcjを入れてみたけどlibgcj.specが????とか出て動かない。かなり険しそう(w
とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
javacで動くように試してみます。

32 :名無しさん@お腹いっぱい。:02/07/09 00:18
>>31
> とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
> javacで動くように試してみます。
1.4のやつって、javacでのコンパイルのみのサポートだったと思います。
# 記憶が曖昧ですみません。
info にもありますけど、.javaと.classのサフィックスルールを自動的に作れ
ない(ファイルの中からクラス名を調査する必要がある)のでそのような仕様だっ
たと思います。だからmakeはできてもmake installは難しいと思います。
# でもうまくいったら教えてください。


33 :名無しさん@お腹いっぱい。:02/07/21 10:19
Autoconf-2.53b 開発版リリース(結構前だけど)
どーでもいいけど、autoconf-mode.elとかautotest-mode.elとかあるのね。
色が変わるだけみたいだけど。

34 :名無しさん@お腹いっぱい。:02/10/02 22:22
知らない間にac-2.54 am-1.7になってたのね。
amのdrilistって便利そうなんだけど使っている人いる?
--confiugre=$HOMEしている人ぐらいなのかな。
# ム板のmmmpスレのほうが活発かな?

35 :名無しさん@お腹いっぱい。:02/10/27 01:33


36 :名無しさん@お腹いっぱい。:02/12/17 00:13
保守

37 :山崎渉:03/01/15 13:25
(^^)

38 :名無しさん@お腹いっぱい。:03/02/01 12:17
autoconfは便利なんだけど、これに対応するようになってから
ソースの見通しが悪くなった。

39 :名無しさん@お腹いっぱい。:03/02/01 21:24
前は環境依存部分を別関数にしたりしてたけど、最近は面倒だからやめた。
確かに見通しは悪くなった。GNUのソースも見るのが辛くなってきた。
# なんか愚痴ばっかりだな。


40 :名無しさん@お腹いっぱい。:03/02/07 11:03
この前からCommon Lispで書かれた数式処理ソフトウェアの構成を
追ってみようとしてるんだけど、main関数のないLispソースを
autotoolsでビルドする構成になってるので、さっぱり分からない。
Autotoolsを使うときには、想定しているコンパイラ・ライブラリの組み合わせと
依存関係を簡単にドキュメント化してくれないと困ってしまう。
逆に移植などがし辛くなってしまうよ。

41 :名無しさん@お腹いっぱい。:03/02/07 18:55
>>40
とりあえずconfigureしてlog見るんじゃだめなの?
Common Lisp知らないからいい加減なこといっているけど。

42 :名無しさん@お腹いっぱい。:03/02/10 18:50
コンパイル型言語じゃないからね、Lispの「メモリダンプ」とかって独特なんです。
で、どんなコマンドが実行されてるんだか
(というか、山ほど実行されてるコマンドのうちどれが重要なのか)分からない。

43 :名無しさん@お腹いっぱい。:03/02/10 21:21
いろいろ大変なんですね。LispはEmacsのしか知らないし、
AM_PATH_LISPDIR使っているものしか見たこと無いんで、
役に立たずですまんです。
# autoconfにもLispファイルがあります。

44 :名無しさん@お腹いっぱい。:03/03/19 10:04
Autoconf,Automake,Libtoolを解説してる本って少ないながらも一応あるようですけど,
どんなもんでしょう?いい本なのでしょうか?

45 :名無しさん@お腹いっぱい。:03/03/19 20:26
多分あの本だと思いますがいい本です。ただし、最新のAutoconf、Automakeを
利用するとちょっと戸惑うかもしれません。セレンディップのGNOMEプログラ
ミングという本にもこれらの解説があります。

46 :名無しさん@お腹いっぱい。:03/03/19 22:57
オーム社の本の事ですか?

47 :名無しさん@お腹いっぱい。:03/03/19 23:47
>>46 そうだと思う。
んでも、少々高いから、漏れは立ち読みで逝こうかとw

48 :名無しさん@お腹いっぱい。:03/03/19 23:59
やっぱりm4マクロの勉強からかな

49 :名無しさん@お腹いっぱい。:03/03/28 06:27
>>48
勉強ってほどのもんでもない。


50 :名無しさん@お腹いっぱい。:03/04/04 19:56
2割、3割はあたりまえ。

51 :山崎渉:03/04/17 12:14
(^^)

52 :山崎渉:03/04/20 06:12
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

53 :名無しさん@お腹いっぱい。:03/05/15 03:41
CVSにconfigureまで突っ込んでるプロジェクトもたまに
ありますが、ふつうはどこまで含めるものなんですか。

54 :名無しさん@お腹いっぱい。:03/05/15 14:14
FreeBSD PORTS なんかだと、
autoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、
古いバージョンも後生大事に用意されていますよね。
これは何故なんでしょうか?
何か後方互換性に大きな問題でもあるのでしょうか?

55 :名無しさん@お腹いっぱい。:03/05/15 16:23
はい。

56 :名無しさん@お腹いっぱい。:03/05/15 16:35
>>55
なるほど。

そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、
といった判断は一般にどのような基準に基づいて行えば良いのでしょうか?

57 :名無しさん@お腹いっぱい。:03/05/15 17:36
>56
違うバージョンを使うと動かないので悩む必要はありません。

58 :名無しさん@お腹いっぱい。:03/05/15 19:54
>>57
う〜ん、やっぱり良くわからないです。

とどのつまり、知りたいのは、
PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、
とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか?
それとも、古いバージョンのも入れておいた方が良いのでしょうか?

59 :名無しさん@お腹いっぱい。:03/05/15 19:59
>>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
>>58
Autotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。
他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが
あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー
スを書いた人が使っているものと同じバージョンがないとうまく動かないこと
もあります。更に、これらのツールは同じprefixにインストールしないとうま
く動かない場合が多いです。

私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、
libtoolだけはいい方法が見つからないです。

61 :>>53:03/05/16 01:00
>>59
さんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。
すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。
configureはtarballに入れればいいし。

62 :名無しさん@お腹いっぱい。:03/05/16 02:39
>>60
どうもです。
私はとくに他人のプロジェクトに参加したりということもなさそうですので、
最新のを入れて問題なさそうですね。

63 :名無しさん@お腹いっぱい。:03/05/17 02:40
とあるソフトの 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
>>63
GNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。
infoコマンドのソースはgdbより少ないかな?

65 :63:03/05/17 18:27
>>64 情報ありがとうございます。当たってみます。

66 :名無しさん@お腹いっぱい。:03/05/19 21:08
済みません、ちょとお邪魔させてください。
事情により初めてautoconf/automake使い始めたとこなんですが、

unyalib--------------------subDirA
  ソ ースいくつか   |       ソースいくつか
               |
               |
               |-----subDirB
                      ソースいくつか

という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、
なおかつ、そのライブラリの一部になっているサブディレクトリにも
ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、



67 :名無しさん@お腹いっぱい。:03/05/19 21:08
解説ページとかを参考にして、

-- 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 :動画直リン:03/05/19 21:12
http://homepage.mac.com/hitomi18/

69 :名無しさん@お腹いっぱい。:03/05/19 21:50
そりゃサブディレクトリでやったらそれぞれ別物だし、
一つのライブラリになるわけはない罠。

70 :67:03/05/19 22:48
えーと、やっぱ駄目ですか。

automakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、
一つのディレクトリに集まっているというのしか想定していないということでしょうか。


71 :名無しさん@お腹いっぱい。:03/05/20 20:14
SUBDIRS使わずに、SOURCESで相対パス指定でできなかったっけ?
$(topsrcdir)とかで指定するんだったかも。
1.4頃の記憶なんで違うかもしれん。
どっちかというとlibtoolsの話かもしれんけどね。

72 :67:03/05/21 21:31
やってみました。

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
>>1
使いにくいのを奥深さと勘違いしてるだけだろ。

74 :>>53:03/05/21 23:52
>>73
奥が深くて使いづらいと申し上げているのです。

75 :名無しさん@お腹いっぱい。:03/05/21 23:52
http://life.fam.cx/


76 :山崎渉:03/05/22 01:44
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

77 :名無しさん@お腹いっぱい。:03/05/23 15:15
makeができない。

78 :名無しさん@お腹いっぱい。:03/05/25 02:38
automakeで作ったMakefileってgmakeに依存する?


79 :名無しさん@お腹いっぱい。:03/05/25 20:45
>>78
基本的には依存しない。Makefile.amの内容によっては依存する。

80 :あぼーん:あぼーん
あぼーん

81 :名無しさん@お腹いっぱい。:03/05/30 15:01
>>73
バッドノウハウと「奥が深い症候群」か。
ttp://namazu.org/~satoru/misc/bad-knowhow.html
こんな単純な問題じゃないと思うけどな。autotoolsがバッドノウハウの塊なのは認めるけど。でも、バッドノウハウがなくなることはないと思うよ、漏れは。

82 :直リン:03/05/30 15:14
http://homepage.mac.com/yuuka20/

83 :_:03/05/30 15:27
http://homepage.mac.com/hiroyuki43/hankaku06.html

84 :81:03/05/30 15:50
>>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
間違えた。
libunyalib_a_LIBADD = libsubdir_a.a ...

libunyalib_a_LIBADD = subdirA/libsubdir_a.a ...
ね。

86 :名無しさん@お腹いっぱい。:03/06/05 21:26
auto* っつーもんは、backward compatibility を放棄した糞ということでよろしいか?

87 :名無しさん@お腹いっぱい。:03/06/06 13:26
Autotools で生成したものの再配布は GNU ライセンスに準じるの?

88 :名無しさん@お腹いっぱい。:03/06/06 21:30
>>87
準じないけど、Automakeで配布されるファイルには
いろんなライセンスがあっはず。
バイナリ配るんなら問題無かったと思う。
>>86
糞かどうかは知らんが、同意したい気分だね。

89 :名無しさん@お腹いっぱい。:03/06/06 22:25
まあ、こいつの登場で便利になっている事実は否定できないので、
backward compatibility を確保して欲しかったということだけかな。


90 :名無しさん@お腹いっぱい。:03/07/14 03:42
backward compatibilityを維持したらどんな事態になるか分るだろ。

91 :名無しさん@お腹いっぱい。:03/07/14 04:11
     ∧_∧∩ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    ( ´∀`)/< 先生!わかりません!!
 _ / /   /   \___________
\⊂ノ ̄ ̄ ̄ ̄\
 ||\        \
 ||\|| ̄ ̄ ̄ ̄ ̄||
 ||  || ̄ ̄ ̄ ̄ ̄||
    .||          ||


92 :山崎 渉:03/07/15 11:27

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

93 :名無しさん@お腹いっぱい。:03/09/14 20:07
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
お騒がせしました。ありました。
http://mail.gnu.org/archive/html/automake/2003-07/msg00018.html
以下のスレッドでした。でもちょっと違うんだよね。困った。

95 :名無しさん@お腹いっぱい。:03/11/20 19:40
犬板にあったので
http://japan.linux.com/desktop/03/11/20/0516251.shtml
個人的にはconfigure時にはbuildなどディレクトリを掘って
../configureのほうが好み。

96 :名無しさん@お腹いっぱい。:03/11/22 09:20
>>95
distclean できる *はず* なので、正直どうでもいい。

97 :名無しさん@お腹いっぱい。:03/11/22 18:24
確かにdistcleanできる *はず* ですね。
個人で開発に利用するときは、cleanすら使うことが少ないから、
良く理解していなかった。

98 :名無しさん@お腹いっぱい。:03/12/27 14:58
./configureしたときのデフォルトの$prefixが/usr/localなのが不便なので、configure.ac
やMakefile.acの中で--prefix=/usrの指定をできないでしょうか?

99 :名無しさん@お腹いっぱい。:03/12/27 16:19
>>98
AC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。

しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの
ではないと思うが。


100 :名無しさん@お腹いっぱい。:03/12/27 16:47
Makefile.ac

101 :名無しさん@お腹いっぱい。:03/12/27 17:02
>>100
ああ、Makefile.amの間違いだよな。

102 :名無しさん@お腹いっぱい。:03/12/27 17:02
>>99
ありがとうございます。
ところでprefixを/usrにするとどういうデメリットがあるのでしょうか?

103 :名無しさん@お腹いっぱい。:03/12/27 17:03
>>101
ごめんなさい。その通りMakefile.amの間違いです。

104 :名無しさん@お腹いっぱい。:03/12/27 18:11
>>102
/usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと
ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。

/usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。
Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い
(衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って
そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。

105 :名無しさん@お腹いっぱい。:03/12/27 19:12
OSの一部として配布されるもの以外は/usrに入れないのが当り前です。
システム上重要というだけでなく、そのOSを使っている人の間で構成が
一致しているからでもある。

Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ
うのも納得できる。
>>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。


106 :名無しさん@お腹いっぱい。:03/12/27 19:44
寄せ集めっつーか、大多数のLinuxディストリにはbase systemと
いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール
したらそれもbase systemの一部だ」みたいなノリなんだろうね。

107 :ヽ(´ー`)ノ:03/12/27 20:30
>>105
Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。
最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。
特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。

> Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
これは、もはや昔話だよもん。


108 :名無しさん@お腹いっぱい。:04/01/07 17:28
一度rpmにするものは/usrにしてる。

109 :名無しさん@お腹いっぱい。:04/02/01 23:20
libtool.m4に入ってるチェックで、Fortranコンパイラを勝手に探したり、
maximum length of command line argumentsとか言ってCPU食うのを
やめさせたいんですけど。そういうACマクロはないんでしょうか?


110 :名無しさん@お腹いっぱい。:04/02/01 23:29
>>109
「勝手」にチェックする m4 なんてない。
configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。
気に入らなきゃチェックしてるところを外せ。
# それでまともにコンパイルできるとは思えんが。


111 :名無しさん@お腹いっぱい。:04/02/01 23:36
えーと言い方が悪かったですが、AC_PROG_LIBTOOLマクロを使うと
ほとんどのパッケージには不要なはずのチェックが盛りだくさんに
はいるわけです。
とりあえず全部チェックしておけばどんな場合にも対応できるってこと
なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、
そういうマクロあります?って話です。
libtool.m4が洗練されてないと言えばそれまでですがね。

112 :名無しさん@お腹いっぱい。:04/02/01 23:53
古いlibtool使うしかないのでは?

113 :名無しさん@お腹いっぱい。:04/02/02 19:06
>>109
AC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、
自分でlibtool.m4を書き換えちゃえば?
うまく動く保証は無いし、libtool使う意味も減ると思うけど。

移植性考えないんならlibtool使わなくてもいいんじゃないかな?


114 :名無しさん@お腹いっぱい。:04/02/04 11:21
移植性を考える考えないの二択ではないでしょう。全プラットフォームの
全項目を保証する気なんてないし、不可能ですから、どこまでチェック
するかの問題ですね。AutoconfにしてもLibtoolにしても。
ですから「移植性考えないならlibtool使わなくていい」なんてのは極論です。

このチェックに関して言えば、ソースのビルド中にコマンドラインの
最大長を超えるコマンドは分割実行するようになっているみたいですが、
環境によっては数分以上かかるようなチェックをするより、4096とか
小さい値を決めうちしたほうがいいですね。実際そうしましたが。
コマンドに4096バイトも入らないプラットフォームは問題外ですから
無視でよいです。デフォルトがチェックになってるのは仕方ないですが。

115 :名無しさん@お腹いっぱい。:04/02/04 12:01
外してたら済まんが、ac_cvなんとかでスキップできんの?

116 :名無しさん@お腹いっぱい。:04/02/04 14:03
たかだか AC_LIBTOOL_SYS_MAX_CMD_LEN のチェックぐらいで数分もかかる
プラットホームは俺の中で問題外なんだけどなw
何のために libtool 使ってんのか分からんよ。

117 :名無しさん@お腹いっぱい。:04/02/04 19:48
>>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
autoconfのドキュメント読んでたら、
$ ./configure --lt_cv_sys_max_cmd_len=4096
でいけるかもしれんような気がした。
しかし、試せない。。。

119 :名無しさん@お腹いっぱい。:04/02/08 09:35
やっと試せた。
>>118
> $ ./configure --lt_cv_sys_max_cmd_len=4096
ではなく、
$ ./configure lt_cv_sys_max_cmd_len=4096
だね。

120 :名無しさん@お腹いっぱい。:04/03/04 19:46
libtool関係の質問はOKですか?>このスレ

121 :名無しさん@お腹いっぱい。:04/03/04 19:55
すぐ上でされてるみたいだけど、とりあえずやってみれば?
問題があれば誘導されるでしょ。

122 :名無しさん@お腹いっぱい。:04/03/04 20:01
configureのコストが、高機能になればなるほどデカクなってきてる
わけですが、これらを動的にチェックするんじゃなくて静的にデータ
ベースのようなもので持たせることはできないですかね。とはいっても
何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう
わけでなかなか難しいんだろうけど。

123 :名無しさん@お腹いっぱい。:04/03/04 20:07
>>122
そのためにはconfig.siteを使えばいいと思うんだけど。


124 :120:04/03/04 21:15
>>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
対して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
pkg-configか?と脊髄反射してみる

127 :名無しさん@お腹いっぱい。:04/03/04 22:09
>>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のほうが新しい方を選択しそうですよね。

偉そうに書いておきながら、よく分からんです。
識者の降臨をお待ちします。

128 :120:04/03/04 23:49
みなさん、すいません。
わからんわからんといいながら、解決してしまいました。

書き込みで両方のログをコピペしたときに、両方の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というより、なんかリンカの問題点だったような気もしてきた。
みなさん、お騒がせしました。

40 KB
■ このスレッドは過去ログ倉庫に格納されています

>>999代わりにああが出てきて1点で当てたじゃん。999万賭けるとあああああするから賭け
金は99万だったけどね。999:ああああ◆9999999999:9999/99/99(あ)
99:99:99.99ID:99999999>>999ああああのああああと申します。ああの
ああ1Rですね。ああですね。1号艇のああはああです。これはあでも分かりますね。2着ですがあ
-ト=/test/read.cgi/unix/1018470294/">★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)