 |
"qt3-3.3.3 コンパイルエラー"
|
"qt3-3.3.3 コンパイルエラー" |
|
Posted by kde on
10-12-04, 06:31 PM (JST)
|
↓の kde-3.3.0 を動かしたくて
http://garage.turbolinux.co.jp/modules/bwiki/index.php?kde-3.3.0最初の qt3-3.3.3 の rebuild でつまずいています  。
必要なソースと、環境はそろえたつもりなのですが。 # rpm --rebuild qt3-3.3.3-2.nosrc.rpm
・
・
kernel/qdragobject.cpp
kernel/qdragobject.cpp: In member function `virtual const char* QImageDrag::format(int) const':
kernel/qdragobject.cpp:1070: internal compiler error: Segmentation fault 環境は TL10D をすべてインストールして、Update したもので、kernel は kernel-2.6.0-15 です。 qt3 を rebuild するために、新たに以下のものをインストールしました。 MySQL-3.23.58-2.i586.rpm
MySQL-client-3.23.58-2.i586.rpm
MySQL-devel-3.23.58-2.i586.rpm
MySQL-shared-3.23.58-2.i586.rpm
perl-DBI-1.37-2.i586.rpm
perl-Net-Daemon-0.37-1.i586.rpm
perl-PlRPC-0.2016-1.i586.rpm
postgresql-7.3-5.i586.rpm
postgresql-devel-7.3-5.i586.rpm
postgresql-libs-7.3-5.i586.rpm
postgresql-odbc-7.3-5.i586.rpm
unixODBC-2.2.0-2.i586.rpm
unixODBC-devel-2.2.0-2.i586.rpm
unixODBC-gui-qt-2.2.0-2.i586.rpm 前途多難ですが、まずどうすれば qt3をリビルド可能でしょうか？
|
|
|
編集 |
![[リプライ]](http://www.turbolinux.co.jp/dcforum/Images/reply.gif) |
![[引用してリプライ]](http://www.turbolinux.co.jp/dcforum/Images/cite-reply.gif) |
![[ポスト]](http://www.turbolinux.co.jp/dcforum/Images/tlpost.gif) | |
|
1. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by kde on
10-12-04, 06:32 PM (JST)
|
もうしわけありません。
なぜか、２つ投稿されてしまいました。
|
|
削除 |
編集 |
|
|
| |
|
2. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by みのむし on
10-13-04, 10:20 AM (JST)
|
># rpm --rebuild qt3-3.3.3-2.nosrc.rpmこのソースパッケージには Qt のソース
(qt-x11-free-3.3.3.tar.bz2)が含まれていません。
一般的に、拡張子が nosrc.rpm のファイルには
本体のソースが含まれていないのが普通です。
よって、別途 qt-x11-free-3.3.3.tar.bz2 をダウンロードして
/var/src/rpm/SOURCES に入れてください。 TROLLTECH Qt/X11 Open Source Edition Download Page
# rpm -ivh qt3-3.3.3-2.nosrc.rpm
(qt-x11-free-3.3.3.tar.bz2 を /tmp に置いていると仮定して)
# cd /var/src/rpm/SOURCES
# mv /tmp/qt-x11-free-3.3.3.tar.bz2 .
# cd ../SPECS
# rpm -bb qt33.spec
|
|
削除 |
編集 |
|
|
| |
 |
|
4. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by みのむし on
10-13-04, 11:58 AM (JST)
|
>書き漏らしましたが、nosrc のパッケージの扱いについては存じております。ならば、「# rpm --rebuild qt3-3.3.3-2.nosrc.rpm」は手順ミスでは？ バイナリパッケージの作成
# rpm --help | less
>当然、qt-x11-free-3.3.3.tar.bz2 ファイルについても
>SOURCE ディレクトリに置いての経過となります。エラーメッセージをここに書いてみては？
なお、私は現在 TL10D が手元に無いのでこれ以上どうする事もできません。
|
|
削除 |
編集 |
|
|
| |
|
|
5. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by kde on
10-13-04, 03:50 PM (JST)
|
お騒がせしました。 root になって /var/src/rpm 下で作業することで先に進みました。私は、rpm の rebuild は $HOME/.rpmmacros で $HOME/rpm を指定し、いつもは
ユーザーレベルで作業していますが qt3 の作成は $PATH の関係かユーザー
レベルではダメなんですね・・・。 一つ勉強いたしました。
>「# rpm --rebuild qt3-3.3.3-2.nosrc.rpm」は手順ミスでは？
NoSourceなソースを入手し rpm/SOURCES に入れておけば、普通に rpm --rebuild で
OKのようですが・・・。 ---- しかし、安心したのもつかの間、これを書いている途中でまた違うところでエラーがでました・・・ g -c -pipe -I/usr/include/mysql -I/usr/include/pgsql -I/usr/include/pgsql/server -fno-exceptions -fPIC -Wall -W -O2 -g -march=i586 -fno-exceptions -finline-functions -DDESIGNER -DQT_INTERNAL_XML -DQT_INTERNAL_WORKSPACE -DQT_INTERNAL_ICONVIEW -DQT_INTERNAL_TABLE -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_SHARED -I/ext/var/src/rpm/BUILD/qt-x11-free-3.3.3/mkspecs/linux-g -I. -I/usr/include/freetype2 -I../shared -I../uilib -I../../../include -I.moc/release-shared/ -o ./layout.o layout.cpp
In file included from layout.cpp:27:
formwindow.h:159: error: `MetaDataBase' was not declared in this scope
formwindow.h:159: error: parse error before `::' token
In file included from layout.cpp:30:
widgetfactory.h:115: error: type specifier omitted for parameter `MetaDataBase'
widgetfactory.h:115: error: parse error before `::' token
widgetfactory.h:259: error: type specifier omitted for parameter `MetaDataBase'
widgetfactory.h:259: error: parse error before `::' token
widgetfactory.h:262: error: `cw' was not declared in this scope
widgetfactory.h:262: error: invalid data member initialization
widgetfactory.h:262: error: (use `=' to initialize static data members)
widgetfactory.h:262: error: ISO C forbids declaration of `setSizePolicy' with no type
widgetfactory.h:263: error: parse error before `if'
widgetfactory.h:267: error: ISO C forbids defining types within return type
widgetfactory.h:267: error: syntax error before `(' token
widgetfactory.h: In function `QString realClassName()':
widgetfactory.h:274: error: `cusw' undeclared (first use this function)
widgetfactory.h:274: error: (Each undeclared identifier is reported only once for each function it appears in.)
widgetfactory.h: At global scope:
widgetfactory.h:275: error: syntax error before `::' token
widgetfactory.h:280: error: syntax error before `::' token
widgetfactory.h:283: error: parse error before `}' token
../../../include/qvaluelist.h:440: confused by earlier errors, bailing out
|
|
削除 |
編集 |
|
|
| |
|
|
9. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by yuki on
10-16-04, 10:48 PM (JST)
|
そのパッケージをダウンロードした所に公開パッケージに関する議論をする
フォーラムがありますのでそこで質問した方が公開者へのフィードバックになる、
…というかここで議論するのは筋違いな気がします。
|
|
削除 |
編集 |
|
|
| |
|
|
11. "RE: qt3-3.3.3 コンパイルエラー" |
|
Posted by 源秀哉 on
10-24-04, 09:22 AM (JST)
|
諸事情により静観しておりました。kde-3.2.3からkde-3.3.0へ移行する間に自分を同じ問題に
ぶち当たり、いろいろ試行錯誤しました。 まず、確認していただきたいのは、現在お使いのPCのメモリは問題ないのか、と言うことです。
http://www.geocities.co.jp/SiliconValley-Oakland/4432/application/memtest86.html
などのページを参考にしてmemtest86というソフトで試してみてください。
（公式サイトには、cd版もおいてありますので、cd版かフロッピー版か、お使いのPCにあわせて選んでください。また、最新版は3.1です。） 次に、PC自身に問題が無い、ことが確認できたら、
1.fedora版のgcc-3.4のバイナリrpmをダウンロードして無理矢理入れてから、qtをコンパイルする。
2.http://pkgcvs.turbolinux.co.jp/~go/Kernel26
から、kernel-2.6.5のバイナリrpmをダウンロードして、入れてから、qtをコンパイルする。
ということになります。 はっきり言って、どちらもかなりリスキーです。
（そのため、余り進めたくは無いのですが...） ちなみに、celica上でコンパイルできないのは別の理由です。そちらは、すでに解決策が判明しているので、近いうちにkde-3.3.1と併せてガレージで公開します。
|
|
削除 |
編集 |
|
|
| |
|
|
13. "サーバーの時間遅れてますよ。" |
|
Posted by minoru on
10-24-04, 02:27 PM (JST)
|
?? いま 15:28 に投稿しましたが（この記事はおそらく 15:30）
ターボさんのサーバーの時間１時間ちょとおくれてますね。
|
|
削除 |
編集 |
|
|
| |
|
|
16. "RE: qt3-3.3.3 コンパイルエラー" |
Posted by ams  on
10-28-04, 00:57 AM (JST)
|
>諸事情により静観しておりました。 暫く、掲示板を見なかったので気づきませんでした。 >まず、確認していただきたいのは、現在お使いのPCのメモリは問題ないのか、と言うことです。
>http://www.geocities.co.jp/SiliconValley-Oakland/4432/application/memtest86.html
>などのページを参考にしてmemtest86というソフトで試してみてください。
>（公式サイトには、cd版もおいてありますので、cd版かフロッピー版か、お使いのPCにあわせて選んでください。また、最新版は3.1です。） GCC ,メモリの件なんですが、あれから色々と調べてみました。元々、私は、UNIX 上でファーム開発をしていて、それから 842ノードほどの Intel Paragon と言う並列機の管理・運用の助っ人で、暫く着任しておりました。 で、これらが、どう関係するのかですが、ファーム開発の場合、エレキ屋さんが、回路設計をして、搭載する OS が制御できるように、CPU メモリ間の転送タイミング（CPU メモリのコントローラーなどのメーカーの仕様で決まってます)を、ある程度の帯域や時間差の許容範囲を考慮して回路が組まれ、実際の基板が作成されます。 基本的に、一般のPCも同様ですね。例え、並列スパコンでも同様です。 で、DRAM の 場合、例え診断ソフトがあっても、ハードウエアの設計、基板や他のパーツの精度とかの問題で、メモリに問題は無くても、パリティー関係のエラーは出ます。スパコンなんかでは、今日の大規模クラスタであれ、24時間運転ですから（月に一回ほど止めてメンテしますが、、、なかなか正常に再起動するのも難しい。)ログを監視していると、ちょこちょこ出ます。が、基本的に、他のエラーとともに計算結果が狂っていると判断されるものでなければ、そのノードの監視を強めるだけで、切り離して止めたりしません。 単純なパリティーのエラーだけでは、OS 側がほんのわずかなデータ転送のずれの境界を転送自体は正常終了していても、エラーと判断することがあるのです。 これは、ファーム開発でも頻発する問題で、RT-OS なんかだと、タスクのプライオリティーを制御してますから、タイマーに引っかかると、それだけで停止する羽目になります。 Z80 なんかでマイコン遊びしていた人には、覚えがあるんじゃないでしょうか。 で、メモリ関係の診断を、ソフトウエアだけでしたからといって、DRAM のトラブルとは断定出来ないことも多くあります。特に、OS と コンパイラのような、大きな負荷がかかり、沢山のプロセスが同時に走っている場合は。 で、スパコンなんかは、怪しいとなると、10 年前で200万円もするボードごと交換し、そのノードの復旧をしていました。勿論、ノードごとに SCSI 40G からの 高速 HD も持ってますから、怪しいエラーが出ていたら、それも交換。 当時、33億円以上もかけて、専用の大規模空調や、専属のオペレータが実行キューに入れる前に、6ノードほどのテスト用（コンパイル用)クラスタで、実行プログラムのチェックをしていて、メモリリークなんかも徹底的に調べてから、本番となっても上記の始末。 SGI ONIXS なんかで可視化してましたけど、G WS でも同じこと。今は、SGI は、Linux 搭載の大規模クラスタを日本メーカーと共同でスパコンとして受注してますけどね。16T FPS とか・・・ 上記の経験上、今回の問題は、特定のタイミングで発生する、OS 側の問題。バグではなくても、i686 で、特にタイミングがシビアになる特定の条件が存在するのだろうと判断しました。 厳密なメーカーテストではありませんけど（こう書かないと、論文並のシートを要求する人もいるし、何を勘違いしているのか、ベンダーテスト以上の多機種、構成でのテスト結果を求める人もいますから。「メモリの不具合の結果」だと決め付けて、他人が、そうとは限らないと言えば、根拠を他人の書いたものに投げるだけで、意味不明の罵詈雑言だけ残して行く人もいますから）Kernel 2.6.7 あたりで、FC2 GCC3.4.1 FC3 GCC4 指定でなくても、Mozilla のような巨大アプリやベースライブラリ(Qt3のような巨大なライブラリも)では、同一マシンで、嘘のように TL10 で不都合だったものが、無事に通ります。 Vine 3.0 Kernel 2.4.27 でも、GCC 3.4.X ,4.0.X 指定の「物」でなければ、エラーなど、全く無しに、同じコードが通ります。これらは、一般的なビルド環境やrpmのバージョンも違いますから。（そういえば、m4 が、30年以上使われているから、バグも不具合も有り得ないという極端な信者もいましたけど。じゃ、m4 利用の、automake autoconf libtool GCC(C,C ) で、連携プレーしているのに組み合わせが狂ったら正常動作にm4 が自動対応するのかと呆れましたけど） それだけに、源さんが、Kernel のバージョンを上げて対応なさったのは、とても重要な要因で且つ賢明な処置だと思います。コンパイラそのものは、3.4 系にしなくても良いはずです。 そもそも、3.4 系は、3.4.1 でさえ、TL10Dでビルドするのは大変(FC2のconfig だとGTK のバージョンまで問われてアウトです。)ですし、TL10D の GCC3.3.1 にバグがあるのなら、他のアプリやライブラリで、とっくに顕在化しているはずです。 結論として、源さんのおっしゃるカーネルのバージョンに上げて、ビルドしてみるか、環境を合わせてバイナリを頂いてくるかじゃないでしょうか。（この場合、Qt3 の指定が、GCC3.4.X ,4 で無い限り、問題なく通ると思いますけど。) もっと単純に、ガレージ（ってどこ？）から全てバイナリで揃えるのでも良いのでは。オフィシャルな環境は、やはり、大きく変更してしまうべきでは無いと思いますから。
ま、メモリテストソフトや東大のπなんかで全負荷をかけてみるのも一つの確認手段ですけどね。前者は既出のとおりで、完全なものでは有り得ませんし、後者は、システム全体のチェックの一種ですね。
長文失礼。
|
|
削除 |
編集 |
|
|
| |
|
Powered by DCForumLite Version 3.0 (C)1997-2000 by DCScripts.
All rights reserved. |
|
印刷する
）