野宮さま
SUSE 9.3 Proj では、パッケージにありますが。 Yast2 のソフトウェアのインストールで、wv をキーワードにして見付かりません か?
フォローありがとうございます。 Yastは一番に調べたのですが、検索でwvで検索しても見つからなかったので 仕方なく、ソースからインストールにチャレンジ中です。 Professional用にパッケージが存在するのは、検索して知っておりますが 使用しているのは、EnterpriseServerですので。
やってみましたら、問題無く make 出来ました。 やはり、./configure で問題が発生していると思いますが。
お手数をお掛けして済みません。 やはり私の設定に問題があるのですね。 試しに、http://ftp.kddilabs.jp/Linux/packages/SuSE/suse/x86_64/9.3/ suse/x86_64/wv-1.0.3-3.x86_64.rpm から、SuSEの何版にあたる物か判りませんが、ダウンロードして入れてみました。 問題無く入っちゃいましたが、これって使い続けて大丈夫なのでしょうか? テスト的に動かした感じでは全く問題無さそうでした。 Enterprise用とは違うので、YOUのUpdateの対象にならないと思うのですが... 以前Novellのサポートセンターに問い合わせた時は 「Professional版とEnterprise版はパッケージが異なるので、kddi等に上がっている パッケージを入れる等、そういった使用方法はしないで下さい。購入時のCDに 含まれるパッケージがEnterprise版の全てです。それ以外はNovellはサポートしませ ん。」 との返答だったので、Professiona版のパッケージは使用せず、ソースから入れてい ます。 表示された内容を確認しながら、判る範囲でパッケージを変更した所、make時のエ ラーが 下記に変わりました。 ./.libs/libwv.so: undefined reference to `libiconv_open' ./.libs/libwv.so: undefined reference to `libiconv_close' ./.libs/libwv.so: undefined reference to `libiconv' collect2: ld returned 1 exit status make[2]: *** [wvSummary] Error 1 make[2]: Leaving directory `/tmp/wv-1.0.3' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/wv-1.0.3' make: *** [all] Error 2 だいぶ絞れてきたと思うのですが、まだlibiconvがおかしいようです。 下記configureの表示中の、checking need for const in iconv... no の部分が原因のように思います。 libiconvは、http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.9.1.tar.gz のものを入れています。 長くなり済みませんがconfigureの結果を下記に引用します。 # ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for gawk... (cached) gawk checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64 checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking io.h usability... no checking io.h presence... no checking for io.h... no checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking for unistd.h... (cached) yes checking for an ANSI C-conforming const... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for gzread in -lz... yes checking png.h usability... yes checking png.h presence... yes checking for png.h... yes checking for pngconf.h... yes checking for png_free in -lpng... yes checking for pkg-config... /usr/bin/pkg-config checking for glib-2.0 >= 2.0... yes checking GLIB_CFLAGS... -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib64/glib-2.0/include checking GLIB_LIBS... -L/opt/gnome/lib64 -lglib-2.0 checking for iconv... yes checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking need for const in iconv... no checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 8 checking whether byte ordering is bigendian... no checking for getopt_long... yes checking for strerror... yes checking for strcasecmp... yes checking for memcpy... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes configure: creating ./config.status config.status: creating wvAbw config.status: creating wvDVI config.status: creating wvPS config.status: creating wvPDF config.status: creating wvHtml config.status: creating wvDocBook config.status: creating wvLatex config.status: creating wvCleanLatex config.status: creating wvText config.status: creating wvWml config.status: creating wv-1.0.pc config.status: creating version.c config.status: creating GNUmakefile config.status: creating magick/GNUmakefile config.status: creating glib-wv/GNUmakefile config.status: creating libole2/GNUmakefile config.status: creating expat/GNUmakefile config.status: creating expat/xmlparse/GNUmakefile config.status: creating expat/xmltok/GNUmakefile config.status: creating exporter/GNUmakefile config.status: creating xml/GNUmakefile config.status: creating help/GNUmakefile config.status: creating help/man/GNUmakefile config.status: creating patterns/GNUmakefile config.status: creating wingdingfont/GNUmakefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands 以上です。
野宮です。 In the Message; Subject : [suse-linux-ja] Re: makeできない Message-ID : <BAY101-F29058378AEE8A1735B20F19F800@phx.gbl> Date & Time: Mon, 03 Oct 2005 18:09:03 +0900 [YMさん] == "Yuko Masui" <arara111@hotmail.com> has written: YMさん> Professional用にパッケージが存在するのは、検索して知っておりますが YMさん> 使用しているのは、EnterpriseServerですので。 そうでしたか。 YMさん> だいぶ絞れてきたと思うのですが、まだlibiconvがおかしいようです。 YMさん> 下記configureの表示中の、checking need for const in iconv... no YMさん> の部分が原因のように思います。 YMさん> libiconvは、http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.9.1.tar.gz YMさん> のものを入れています。 libiconv 絡みのようですね。 小生は、libiconv を入れていません。恐らく、ImageMagick がその役目を果たして いると考えています。 YMさん> 長くなり済みませんがconfigureの結果を下記に引用します。 [...] YMさん> 以上です。 小生のと同じです。 --- 野宮 賢 mail-to: nomiyac360@mg.point.ne.jp 「eメールや携帯電話に縛られた社会は、自分自身と向き合ったり、 空想にふけったりする自由を奪う。」 -- M. Crichton --
M. Takeyamaです。 On Mon, 03 Oct 2005 19:00:15 +0900 野宮 賢 / NOMIYA Masaru <nomiyac360@mg.point.ne.jp> wrote:
野宮です。
YMさん> だいぶ絞れてきたと思うのですが、まだlibiconvがおかしいようです。 YMさん> 下記configureの表示中の、checking need for const in iconv... no YMさん> の部分が原因のように思います。 YMさん> libiconvは、http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.9.1.tar.gz YMさん> のものを入れています。 Linux(rpm)を使っているのに、各パッケージの依存関係まで崩して 対処する/対処しないは別として...
仮に、自分の再ビルドしたい wv-1.0.3が本当に手動でインストール した(libiconv-1.9.1.tar.gz)libiconvを参照していますか? configure のオプションで明示的に指定していますか? #参照しているライブライとかヘッダーと要求されているlibiconv #のバージョンが違うから、 undefined reference to `libiconv_open' #といっているのではないでしょうか。
libiconv 絡みのようですね。 小生は、libiconv を入れていません。恐らく、ImageMagick がその役目を果たして いると考えています。 通常、/usr/bin/iconv コマンドは、libiconvを参照していないと思います。 ldd /usr/bin/iconv or /usr/bin/iconv --version で確認できます。(GNUのlibcを参照しています。)
<libiconvのバグだとしたら...(回避法)> 1) php4-iconv で事足りるかもしれません。 #libc(バージョン)に依存しないように独自に iconv とか libiconv #をもっていたはずです。 2) libcのバグだという。--- 言い方(と明確な根拠がある場合に)。 SLES9 だと別途契約して”SUSE LINUXサーバサポート”を受ければ レベル3(L3)だったら、パッチ提供があるのでは。 http://support-j.novell.co.jp/additional/nss-description.html --- M. Takeyama -------------------------------------- Know more about Breast Cancer http://pr.mail.yahoo.co.jp/pinkribbon/
今井です。 ちょっと小言も入ってます.....。 最初に使ってるマシンが64bitマシンである事書くべきだったので はないかと思いますが....? でもって9.3/suse/x86_64と同じ階層(9.3/suse/src)にsrc.rpm パッケージがあるのですが、そちらをインストールして /usr/src/packages/SPECS ディレクトリからバイナリrpmパッケージビルドしてみるとどうなりますか? src.rpmからバイナリRPMパッケージ作る場合でも中でやってるのは ソースからのコンパイルと一緒ですから参考になると思います。 うちのOpteronマシンでは9.3Jでコンパイル通ってバイナリrpmパッケージ つくれました。 SLES 9とはカーネルやらコンパイラ、ライブラリのバージョン違うので微妙な ところありますが。 64bit版だと色々追加でオプションを指定しなければいけない場合が あるのでただ./configureしてもダメな場合が結構あります。 かくいう私もALSAのライブラリとかコンパイルする時それを忘れて はまってましたけど....。 月曜日 03 10月 2005 18:09、Yuko Masui さんは書きました:
フォローありがとうございます。 Yastは一番に調べたのですが、検索でwvで検索しても見つからなかったので 仕方なく、ソースからインストールにチャレンジ中です。
Professional用にパッケージが存在するのは、検索して知っておりますが 使用しているのは、EnterpriseServerですので。
やってみましたら、問題無く make 出来ました。 やはり、./configure で問題が発生していると思いますが。
お手数をお掛けして済みません。 やはり私の設定に問題があるのですね。
試しに、http://ftp.kddilabs.jp/Linux/packages/SuSE/suse/x86_64/9.3/ suse/x86_64/wv-1.0.3-3.x86_64.rpm から、SuSEの何版にあたる物か判りませんが、ダウンロードして入れてみました。
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
野宮です。 In the Message; Subject : Re: [suse-linux-ja] Re: makeできない Message-ID : <200510032105.32105.maimai@coral.ocn.ne.jp> Date & Time: Mon, 3 Oct 2005 21:05:31 +0900 [今井さん] == Masaru Imai <maimai@coral.ocn.ne.jp> has written: 今井さん> 64bit版だと色々追加でオプションを指定しなければいけない場合が 今井さん> あるのでただ./configureしてもダメな場合が結構あります。 これは、./configure --help で解るものなんでしょうか? 後学の為、お教え下さい。m(_ _)m --- 野宮 賢 mail-to: nomiyac360@mg.point.ne.jp "Bill! You married with Computers. Not with Me!" "No..., with money."
今井です。 月曜日 03 10月 2005 21:12、野宮 賢 / NOMIYA Masaru さんは書きました:
これは、./configure --help で解るものなんでしょうか?
後学の為、お教え下さい。m(_ _)m
微妙ですね。 さーっと読み流してしまえば分からないけど、そのつもり?で読めば....。 32bit版ならxxxで64bit版なら.....。 というのは期待しない方がよろしいかと。 32bit版と64bit版で何が違う、何を違えるのかというのをコンパイルする 人が分かってないことには....。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
野宮です。 In the Message; Subject : Re: [suse-linux-ja] Re: makeできない Message-ID : <200510032140.27967.maimai@coral.ocn.ne.jp> Date & Time: Mon, 3 Oct 2005 21:40:27 +0900 [今井さん] == Masaru Imai <maimai@coral.ocn.ne.jp> has written: 小生> > これは、./configure --help で解るものなんでしょうか? 今井さん> 微妙ですね。 今井さん> さーっと読み流してしまえば分からないけど、そのつもり?で読めば....。 今井さん> 32bit版ならxxxで64bit版なら.....。 今井さん> というのは期待しない方がよろしいかと。 今井さん> 32bit版と64bit版で何が違う、何を違えるのかというのをコンパイルする 今井さん> 人が分かってないことには....。 一種の謎掛けのようで.... (_ _? しかし、Takeyamaさんのアドヴァイスを読むと、32bitの場合と同じ考え方で良いよ うに思えますが? # Fixed Ghostscript for SUSE 9.3 は出さない、という返事が来ました。(T_T) --- 野宮 賢 mail-to: nomiyac360@mg.point.ne.jp 「eメールや携帯電話に縛られた社会は、自分自身と向き合ったり、 空想にふけったりする自由を奪う。」 -- M. Crichton --
今井です。 月曜日 03 10月 2005 22:58、野宮 賢 / NOMIYA Masaru さんは書きました:
一種の謎掛けのようで.... (_ _?
しかし、Takeyamaさんのアドヴァイスを読むと、32bitの場合と同じ考え方で良いよ うに思えますが?
32bit版DLLと64bit版実行ファイル 64bit版DLLと32bit版実行ファイル の組合わせは出来ないということ。 32bit版なら32bit版のDLLと実行ファイルしか無いので問題にはなりませんが、 64bit版だと32bitと64bit環境が共存なのでこの問題があるのです。 体系的には64bit環境が拡張部みたいな実装の仕方なので何にも指定しないと オリジナル?という位置づけの32bit環境を使おうとします。 でもってconfigureではこの辺りを勝手に判断してくれないので、使う人がその辺り どうするのか明示しないと32bit版DLLを64bit版DLLで上書きとかいう事になります。 configure --helpしても64bit版ならこうしなさいとか出ませんから使う人が知識として 持ってないことにはどうしようもないのです。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
野宮です。 In the Message; Subject : Re: [suse-linux-ja] Re: makeできない Message-ID : <200510032313.54210.maimai@coral.ocn.ne.jp> Date & Time: Mon, 3 Oct 2005 23:13:54 +0900 [今井さん] == Masaru Imai <maimai@coral.ocn.ne.jp> has written: 小生> > しかし、Takeyamaさんのアドヴァイスを読むと、32bitの場合と同じ考え方で良いよ 小生> > うに思えますが? 今井さん> 32bit版DLLと64bit版実行ファイル 今井さん> 64bit版DLLと32bit版実行ファイル 今井さん> の組合わせは出来ないということ。 今井さん> 32bit版なら32bit版のDLLと実行ファイルしか無いので問題にはなりませんが、 今井さん> 64bit版だと32bitと64bit環境が共存なのでこの問題があるのです。 今井さん> 体系的には64bit環境が拡張部みたいな実装の仕方なので何にも指定しないと 今井さん> オリジナル?という位置づけの32bit環境を使おうとします。 今井さん> でもってconfigureではこの辺りを勝手に判断してくれないので、使う人がその辺り 今井さん> どうするのか明示しないと32bit版DLLを64bit版DLLで上書きとかいう事になります。 う〜む、難しいんですねぇ〜.... と、すると、Masuiさんが 32bit 版の vmWare rpm を入れたりするのはまずい、と いうことになりますね。つまり、問題がなければ、パッケージングされている筈と 思うのですが。 今井さん> configure --helpしても64bit版ならこうしなさいとか出ませんから使う人が 今井さん> 知識として持ってないことにはどうしようもないのです。 Novellのサポートが他のrpmファイルを入れるな、というのは、コンパイルもするな、 という意味にもなりますか。 --- 野宮 賢 mail-to: nomiyac360@mg.point.ne.jp 「eメールや携帯電話に縛られた社会は、自分自身と向き合ったり、 空想にふけったりする自由を奪う。」 -- M. Crichton --
今井です。 月曜日 03 10月 2005 23:29、野宮 賢 / NOMIYA Masaru さんは書きました:
う〜む、難しいんですねぇ〜....
と、すると、Masuiさんが 32bit 版の vmWare rpm を入れたりするのはまずい、と いうことになりますね。つまり、問題がなければ、パッケージングされている筈と 思うのですが。
? Masuiさんが入れてるwvWareは64bit版なんで別に問題無いと思うんですが.....。 64bit版に32bit版rpmを入れるのは同一パッケージが64bit版に存在し、かつインストール されていない限り問題無しです。 そうでない場合にはlibはlibとlib64に分かれてますがbinはbinだけなのでパスを変更す るなどの方法で対応するとユーザの方で起動してるのが32bit版、64bit版でごちゃまぜに なり、前述のDLLと実行ファイルの問題があるので新たな問題起きますし、管理する人間 の方が混乱します。 いずれにせよ自分で入れたものは「自己責任で」ということで、自分で責任取れるなら 何でもありかと思いますが....。 ただ一個人の所有物でないものに対してそれをやるのはまた別の意味で得策ではない と思いますが。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M. Takeyamaです。 #補足説明モード On Mon, 03 Oct 2005 23:29:38 +0900 野宮 賢 / NOMIYA Masaru <nomiyac360@mg.point.ne.jp> wrote:
野宮です。
In the Message;
Subject : Re: [suse-linux-ja] Re: makeできない Message-ID : <200510032313.54210.maimai@coral.ocn.ne.jp> Date & Time: Mon, 3 Oct 2005 23:13:54 +0900
[今井さん] == Masaru Imai <maimai@coral.ocn.ne.jp> has written:
小生> > しかし、Takeyamaさんのアドヴァイスを読むと、32bitの場合と 小生> > 同じ考え方で良いように思えますが? 問題は既に解決したようですが補足説明。 良く経過(過去メール)を読んでみると 64bit依存(64bit環境) の問題だということがわかったかもしれませんが, 単純に、私はそれ以前(32bit/64bitに関係なく)の問題ように 思えたものですから...
./configure; make; make install; て、かなり環境に依存しますね。
今井さん> でもってconfigureではこの辺りを勝手に判断してくれないので、使う人がその辺り 今井さん> どうするのか明示しないと32bit版DLLを64bit版DLLで上書きとかいう事になります。
う〜む、難しいんですねぇ〜....
と、すると、Masuiさんが 32bit 版の vmWare rpm を入れたりするのはまずい、と いうことになりますね。つまり、問題がなければ、パッケージングされている筈と 思うのですが。 元々、SLES9にvmのパッケージが無いのは、商品の性格(サーバ用途) だからだと思います。
今井さん> configure --helpしても64bit版ならこうしなさいとか出ませんから使う人が 今井さん> 知識として持ってないことにはどうしようもないのです。
Novellのサポートが他のrpmファイルを入れるな、というのは、コンパイルもするな、 という意味にもなりますか。 コンパイルはOKでしょう。 他のディスロや他のバージョンをインストールして混ぜると サポートできなくなるから禁止ということだと思います。 #検証できる環境が共通化できなければ、原因の特定が出来ないと #思います。
商用アプリやSLES9にないrpmは、別途相談になるのではないでしょうか? --- M. Takeyama -------------------------------------- Know more about Breast Cancer http://pr.mail.yahoo.co.jp/pinkribbon/
M. Takeyamaです。 #ピンポイントで。 #くどいようですけど... On Mon, 3 Oct 2005 23:13:54 +0900 Masaru Imai <maimai@coral.ocn.ne.jp> wrote:
今井です。
[...]
configure --helpしても64bit版ならこうしなさいとか出ませんから使う人が知識として 持ってないことにはどうしようもないのです。 Linuxの64bit環境はもっていませんが...
configure --helpで、 --enable-64bit みたいなオプション表示 がされることがあっても全ての場合で、そうではないような気がします。 #それで十分な場合もあるし、それだけではダメとか。 つまり、ソースコードの64bit対応レベルよる and そのこと知っている人でないとビルドは辛いかも。 #オープンソースの開発者側も 100% 64bitを意識して #書いているわけではないと思います。 #(だから、64bit用のパッチが必要なケースもあるわけで。) 64bitの環境を把握していて、configure --help したり README, HELP ファイルを読んでビルドする必要があると いうことだと思います。 --- M. Takeyama -------------------------------------- Know more about Breast Cancer http://pr.mail.yahoo.co.jp/pinkribbon/
At Tue, 04 Oct 2005 20:34:41 +0900, M. Takeyama(takezou) wrote:
M. Takeyamaです。 #ピンポイントで。 #くどいようですけど...
On Mon, 3 Oct 2005 23:13:54 +0900 Masaru Imai <maimai@coral.ocn.ne.jp> wrote:
今井です。
[...]
configure --helpしても64bit版ならこうしなさいとか出ませんから使う人が知識として 持ってないことにはどうしようもないのです。 Linuxの64bit環境はもっていませんが...
configure --helpで、 --enable-64bit みたいなオプション表示 がされることがあっても全ての場合で、そうではないような気がします。 #それで十分な場合もあるし、それだけではダメとか。
つまり、ソースコードの64bit対応レベルよる and そのこと知っている人でないとビルドは辛いかも。 #オープンソースの開発者側も 100% 64bitを意識して #書いているわけではないと思います。 #(だから、64bit用のパッチが必要なケースもあるわけで。)
64bitの環境を把握していて、configure --help したり README, HELP ファイルを読んでビルドする必要があると いうことだと思います。
build 自体は結構うまくいくことが多いですよ。 もちろん configure の出力を良くチェックする、というのはどの architecture でも必要な事ですが。 で、AMD64 などの architecture で一番忘れがちなのが --libdir=/usr/lib64 といった指定です。 質が悪いのが、新しいライブラリは /usr/lib にインストールされ、 /usr/lib64 に残っている古いライブラリがリンクされる状態ですね。 一見まともに動いているように見えるのに、実は古いまま、という。 -- Takashi Iwai <tiwai@suse.de> ALSA Developer - www.alsa-project.org
今井です。 火曜日 04 10月 2005 21:31、Takashi Iwai さんは書きました:
で、AMD64 などの architecture で一番忘れがちなのが --libdir=/usr/lib64 といった指定です。 質が悪いのが、新しいライブラリは /usr/lib にインストールされ、 /usr/lib64 に残っている古いライブラリがリンクされる状態ですね。 一見まともに動いているように見えるのに、実は古いまま、という。
過去に私がはまってたパターンですね....。 変な思い込みでなぜかALSAでのconfigureでだけはそれやらなかったんだが、 それが悪かったという事で.....。 気がつけば/usr/libにあるALSAの32bit版ライブラリを64bit版で上書きしてて、 リンクする際は/usr/lib64にある古い方のライブラリリンクしてたという...。 そのまんまですね。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp web: http://www10.ocn.ne.jp/~masimai/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
participants (5)
-
M. Takeyama(takezou)
-
Masaru Imai
-
Takashi Iwai
-
Yuko Masui
-
野宮 賢 / NOMIYA Masaru