Arch Linux 18 (993ﾚｽ)
上下前次1-新
337(1): 05/13(月)19:24 ID:rUUCKSVL(1) AAS
ビルドを/tmpでやってるんじゃないの？
338(1): 05/13(月)19:32 ID:9hMkpwq+(1) AAS
>>335
俺も16GB載せてるが2、3回に1度くらいの頻度で失敗するわ
339: 05/13(月)19:40 ID:C3pTaN2D(3/3) AAS
>>337
いえ。ユーザーのhomeディレクトリで
やってますよ。
340(2): 05/13(月)21:23 ID:9v9+0sEy(1) AAS
環境によるビルドエラーというよりgccとコンパイルオプションの問題なのかな…?
g++のbasic_stringライブラリ側で内部変数'_M_allocated_capacity'が適切に初期化されてないぽいような
gcc側の問題ならclangにして回避するか-Werror=maybe-uninitializedオプションを外すとか
>-Werror=maybe-uninitialized
初期化されない場合、その警告をコンパイルエラーとして扱う指定
>cc1plus: all warnings being treated as errors
プリプロセッサかコンパイラあたりが警告をコンパイルエラーとして吐き出してる
341(1): 05/13(月)22:02 ID:zteuBQbN(3/3) AAS
いつもでやってんのofficalのビルド環境がubuntu24.04になったんだから
clangがデフォだよ
342: 05/13(月)22:56 ID:pgrGXMrf(2/9) AAS
>>335
> 報告でした。
うおお偉い！まさか報告があるとは思わなかった。
まあ、インストールなんて所詮作業でしか無いから、何度やっても慣れてもほぼ無意味。
こういう引っかかったところで地道にデバッグして経験値を積み、Linuxのパワーレベル(戦闘力)を上げて行くのは正しいと思うぜ。
現状知らんので以下色々間違ってるかもしれんが、分かるところを書いておく。
まず状況を纏めると、
A. メモリ8GB, スワップ不明で、エラー(328)
B. メモリ8GB, スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(334)
C. メモリ16GB、スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(335、後半のエラー内容は328と同じだが…)
省4
343: 05/13(月)22:57 ID:pgrGXMrf(3/9) AAS
さて上記からまず思うのは、
(a) sudo systemctl stop systemd-oomd は効いたらしい？
(b) メモリは16GBでも駄目？
だが、よくよく見ると、
A(328)
INFO: Elapsed time: 334.405s, Critical Path: 39.55s
INFO: 1055 processes: 511 internal, 544 linux-sandbox.
B(334)
INFO: Elapsed time: 431.637s, Critical Path: 39.20s
INFO: 1148 processes: 511 internal, 637 linux-sandbox.
省13
344: ころころ 05/13(月)22:58 ID:pgrGXMrf(4/9) AAS
しかしまあここまでは所詮はデバッグ上の保険であって、これより以下が本命になる。
B,Cの前半見て分かるとおり、B,Cは明確にソースコード起因で落ちてる。
> [-Werror=maybe-uninitialized]
> cc1plus: all warnings being treated as errors
つまり、>>340の言うとおりで、
未初期化(っぽい)のを警告とし、cc1で警告は全てエラー扱いにしてるから落ちてる。
だからこれらを外してしまえば、少なくとも現在落ちてるところは通るようになる。
一般的な問題としては、
> cc1plus: all warnings being treated as errors
であり、そもそもC言語の文化では警告上等(＝警告は無視するもの)であり、
省10
345(1): 05/13(月)22:59 ID:pgrGXMrf(5/9) AAS
だから、解決策としては、
α：リリース時のgccバージョンでコンパイルする(通常はダウングレードすることになる)
β：オプションを調整して警告無視でコンパイルする
であり、archの場合はパッケージリリース時のgccバージョンが多分明確に分かるはずなので、
まずそれを調べ、
α-1：もしリリース時のgccバージョンよりも現在使用しているもののバージョンが低いのなら、アップデートしてビルドを試す。
α-2：ただし通常はダウングレードになってしまうと思われるので、こちらは面倒だからやらず、
β：オプションを調整してビルド、
になる。（つっても面倒ならgccが最新版であることを確認してβだけでいい)
346: 05/13(月)23:00 ID:pgrGXMrf(6/9) AAS
最近C言語やって無いので以下は勘であり間違ってるかもしれんが、
-Wはマクロであり、通常は環境変数で指定する。
configure時代は大体 CCFLAGS=-Wall みたいな指定方法だったが、今は知らん。
ただ上記も「追加」であり、「削除」はどこにどう指定するのかは分からん。
もし、パッケージビルドといってもガワ被せただけで結局configureしてるのなら、多分configure自体かそこから呼ばれるbashスクリプト内で
export CCFLAGS=-Wall とかでデフォのオプションを指定してるはずだから、その辺を弄ることになる。
この場合はとりあえず grep 'maybe-uninitialized' * とかで探すことになる。
347(1): 05/13(月)23:02 ID:pgrGXMrf(7/9) AAS
-Wall ：全ての警告を表示しろ、の指示
-Wunused-but-set-parameter ：変数に代入してるが使ってねえじゃん馬鹿ヤロー、と警告出せ、の指示
-Wallと被ってるから意味無い？まあそのとおりだが、この辺はダブっても問題ない、というノリ
そしてこの通り、全部の警告を出す＝動作上は問題ないけどソースコードをもっときれいに出来るよね、も警告になる
348: 05/13(月)23:02 ID:pgrGXMrf(8/9) AAS
だから自分でコード書くときは「全部の警告を出し、全部の警告を消す」ようにコードを整理するのが理想で、
多分このプロジェクトでもやってたんだろうが、その後gccのバージョンが上がり、新たな警告を出せるようになった場合は通らなくなる
349: 05/13(月)23:03 ID:pgrGXMrf(9/9) AAS
-Werror=maybe-uninitialized：未初期化(かもしれない)変数を使用してたらエラーにしろ、の指示
ただ言っちゃ悪いがC言語の文法では未初期化は検出できないので、
(ある程度実績のあるプロジェクトなら)これは誤検出であり多分やりすぎなので切っていい)
なので、-Werror=maybe-uninitialized は勿論消すとして、
他に
> cc1plus: all warnings being treated as errors
を指示してるマクロがあるはずなので、それも消してビルドを試せばいい。
これについてはエラーログの
> (remaining 62 arguments skipped)
の部分をとりあえず全部表示させてコピペしてくれればそれっぽいの探せるけど。
省13
350(1): 05/14(火)00:16 ID:H9yYz+Wx(1) AAS
単にbeing以下がwarningに形容詞的に掛かって全体としては名詞となっているだけかと
351(2): 05/14(火)01:29 ID:Ppv6XzUu(1) AAS
file not found(名詞) と file is not found(文) みたいな
意味としてはほぼ同じになりますか
352(2): 05/14(火)01:31 ID:x+9d/xHb(1) AAS
>>350-351
A. all warnings ARE BEING treated as errors ←分かる、受動態の進行形、「全ての警告はエラーとして扱われている」
B. all warnings treated as errors ←分かる、文法用語で何かは分からんが、意味は「エラー扱いの全ての警告」、過去分詞が形容詞的に使われてるだけ
C. all warnings BEING treated as errors ←分からん、わざわざBEINGをブチ込んで来る必要ないのでは？まあ意味は上記Bと同じだとは推測できるが。
Bだと、
all (warnings treated as errors) 「エラー扱いの警告の全て」
(all warnings) treated as errors 「全ての警告はエラー扱い」(厳密には「は」だと文になってしまうので間違いだが、いい日本語訳が思いつかない)
が曖昧なので、BEING入れたら明示的に下側になるのか？なら最初からAでいい気もするが。(もしかしてBだと文法違反？)
てな感じ。
とはいえ、よく考えたらインターネットなんだしアメリカ人に上記ABCの違い聞けばいいだけだからそうしてみるわ。
省1
353: 05/14(火)02:59 ID:0wI0UVNc(1) AAS
こんばんは。
mozc-utで苦しんでた者です。
ふと見ると、昨日付けでmozc-ut、fcitx5-mozc-ut
のバージョンが上がってました。
git pull して再ビルド。
gcc13を依存関係で要求されて入れました。
これでメモリ8GBでも、ビルド成功しました。★
皆さま、お力添ありがとうございました。
勉強になり、貴重な体験が出来ました。
しかしこういう問題に当たった時に
省4
354: 05/14(火)03:26 ID:1fC9FryG(1) AAS
mozc 2.30.5448.102-2になってるね
-makedepends=('bazel' 'git' 'python')
+makedepends=('bazel' 'git' 'python' 'gcc13')
355(1): 05/20(月)14:17 ID:/6ZD7P2t(1) AAS
>>352
Aだとありとあらゆる警告がエラーと同義になるから意味合いが変わってくるんじゃね
treatが自動詞なのか受身なのか一目で判別しやすいようにつけてるんだとは思うけど、「現状の」という意味合いも一応兼ねてると思う
356: 05/20(月)21:35 ID:UvwOctiA(1) AAS
またmozcが馬鹿になってると思ったら...
上下前次1-新書関写板覧索設栞歴
あと 637 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.009s