0001login:Penguin2023/12/28(木) 20:59:40.30ID:o+WHp/AG
>>306
やっぱり問題にはなってたのね
最新版が入るのはいつになるか分からないし諦めてrbenv使うかあ
なるべくpacmanで完結したいんだけどな 最近はちょくちょくパッケージのメンテナが連絡不能になっているから
ユーザーは増えてきても実際には末期状態かもしれないな
0309login:Penguin2024/04/25(木) 07:01:10.17ID:DHendrMY
rubyってちょっと油断するといつのまにか入れられるんだよね。
pythonは諦めてる(一応自分でも使ってる)けど、rubyまで滑り込んでくるのは我慢ならない。
>>309
数少ない国産の有名言語だから(比較的)
無下にしないであげて…自分は入れてないけども システムアプデ後にあるパッケージのsystemd daemonが起動せず
とりあえずパッケージのリビルドでまた起動するようにはなったけれど
たぶん依存パッケージの指定がどれか漏れてるとかなんだろうけどどのパッケージに依存しているか不明っていう\(^o^)/
0312login:Penguin2024/04/28(日) 16:58:44.97ID:TD/1Xpsj
昨日辺りでpythonが上がったからな。しばらくすったもんだするかも。
0313login:Penguin2024/04/28(日) 21:26:43.02ID:D/L954Af
cups がプリンタを見つけられなくなった。
1つ前にダウングレードしたら復活。
バグトラッカーが使いにくくなったなあ…
kittyとweztermがまともに動かなくなったぜ
なぜかalacrittyだけ無事だった
icu が上がったらおまえらキレそうだな
ffmpeg も同時に上がったら発狂しそうだな
>>312
そーだったのかw
chirp-nextが起動不能になったもんだから、ターミナルで起動
してエラーメッセージみたら納得したw fcitx5デーモンを立ち上げない場合端末の不具合は発生しない…つまり原因は…
archlinux.jpのssl証明書、期限切れじゃないか?
久々にArchで環境作ったら
mozc、mozc-ut共
AURでビルドエラーで止まる。
いつか直るかな。
とりあえずanthy使ってる。
0322login:Penguin2024/05/11(土) 18:37:09.48ID:2tUA/r1D
>>321
DEなんだか知らないけど、 fcitx5-mozcならリポジトリにありますので
mozc使うなら、fcitx5がいいですよ 0323login:Penguin2024/05/12(日) 08:29:50.78ID:VRNQJeMw
>>321
mozc-utだけど自分の環境ではちゃんとビルドできてるな
自分の経験上メモリが8GB未満なら必ず失敗する
とりあえず~/.cache/bazelを削除して再ビルドするのがいいかも
なぜかArch公式のfcitx5-mozc勧めてる人いるけど古いしemacs mozcが使えなくなるから使ってる人はいないと思う >>323
横だし話はまったく別だが、
> 自分の経験上メモリが8GB未満なら必ず失敗する
これマジ?最近の状況全く知らんが、そもそも論として、ビルドに8GB食うとは思えないし、
食ったとしてもスワップ行くだけ、つまり遅いだけで通るはずなのだが。
(少なくともWindowsならスワップは自動増加がデフォなのでメモリが足りなくて落ちることはない。クソ遅くはなるが。
そしてLinuxには未だにスワップを自動増加する設定がなさそうなのはショボ過ぎだが) 0325login:Penguin2024/05/12(日) 14:40:44.63ID:d4bT51jn
>>323
emacsってデフォアプリなんすか?
私のArchには入ってませんけど
ビルドでコケるよりはマシな気がしますが… >>322
入れました。
fcitx5-mozcだけで、使えるのですね。
mozcというパッケージが必要と思い込んでいました。
古いらしいですが、特に問題無いので
このパッケージのを使います。
ありがとう。 >>323
メモリ、8GBちょうどなんですけどね。😥
もう一回ビルドしてみます。 >>323
~/.cache/bazelを削除して(実はこれも前回やりましたが)、
ERROR: /home/yamato99999/aur/mozc-ut/src/mozc-ut-git/src/protocol/BUILD.bazel:140:14 Compiling protocol/user_dictionary_storage.pb.cc failed: (Exit 1): gcc failed: error executing CppCompile command (from target @@com_google_protobuf//src/google/protobuf:protobuf) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 62 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Elapsed time: 334.405s, Critical Path: 39.55s
INFO: 1055 processes: 511 internal, 544 linux-sandbox.
ERROR: Build did NOT complete successfully
==> エラー: build() で問題が発生しました。
中止...
mozc-ut
こんなエラーでビルド止まります。
mozc
も同じです。
何でしょね? 噂ではswap領域が十分でもsystemd-oomdが強制終了させるという話がありますね
他の環境(fedora)自前でmozc buildしてるけど最近のgccじゃ通らんclangで完走した
0331login:Penguin2024/05/13(月) 07:48:08.13ID:ELtAGQGa
やっぱりbazelは面倒だな
mozc-utはもはやArch必須パッケージみたいなものだからなんとかしてほしいところ
UT辞書はライセンスバカがしょーもないことを触れ回ったせいでビルド済みバイナリを配布するのも難しい状況だし
CC=clang CPP=clang++ bazel .....
環境変数つけるだけじゃ?
>>329
> Mozc のビルドに失敗する (プロセスが強制終了される)
> ビルドが以下のようなメッセージで異常終了した場合:
>
> ...
> /bin/sh: 1 行: xxxx 強制終了
> ...
> make: *** [xxx/xxx ...] エラー 137
> ...
> メモリ不足になっていないか確認してください。
> ttps://wiki.archlinux.jp/index.php/Mozc
のとおり、実際にメモリ不足になると止まるように設定されているようだ。また、
> 従来はメモリー不足によりOSの応答性が著しく低下し、もしくは無反応になり、
> ユーザーはPCを強制的に再起動せざるを得ませんでした。
> この状況を改善するため「systemd-oomd」を導入し、
> システム的にメモリー不足に陥る前にユーザースペースで「OOM Killer」を実行してメモリーの空き容量を確保し、
> システムの応答性低下を緩和することになりました。
> ttps://kledgeb.blogspot.com/2022/07/ubuntu-2204-224-systemd-oomd.html
とあるから、とりあえずはビンゴっぽい。そのページの下のほうに書いてあるが、一時的に停止するには
> sudo systemctl stop systemd-oomd
だとさ。archでも全く同じかは知らんが。
ただまあ、ビルドに8GB食うのはおかしいと思うから、多分どれかのツールがメモリリークしてるのだろうが、
ディストリ側としてはどうにもならんから、この対処なのだろう。
(普通に考えれば、これならarchWikiに一時的解除の方法を載せれば良いだけだが、
それよりはメモリ不足で諦めさせたほうがいい、という判断になっているのは、
おそらく一時的に解除してビルドした場合、実際に再起動せざるを得ないケースに遭遇することになる、ということなのだろう)
というわけで、確定させたければ再起動上等で試してみるんだね。 >>333
> sudo systemctl stop systemd-oomd
まずこれをやって、~/.cache/bazel を削除。
で、ビルドするとエラーが少し変わったかな↓
/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/basic_string.h:1182:30: error: '*(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)((char*)<unknown> + 8).std::__cxx11::basic_string<char>::<anonymous>.std::__cxx11::basic_string<char>::<unnamed union>::_M_allocated_capacity' may be used uninitialized [-Werror=maybe-uninitialized]
1182 | return _M_is_local() ? size_type(_S_local_capacity)
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1183 | : _M_allocated_capacity;
| ~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 431.637s, Critical Path: 39.20s
INFO: 1148 processes: 511 internal, 637 linux-sandbox.
ERROR: Build did NOT complete successfully
==> エラー: build() で問題が発生しました。
中止...
やっぱりビルド失敗。
で、原始的にPCのメモリが有ったので
16GBにして、~/.cache/bazel を削除。
で、再ビルド。
でも↑と同じエラーで止まる。
↓続く >>333
3回目。> sudo systemctl stop systemd-oomd
これをやって、~/.cache/bazel を削除。
メモリ16GBで再再ビルド。
エラーが前回に戻ったかな↓
/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/basic_string.h:1182:30: error: '*(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)((char*)<unknown> + 8).std::__cxx11::basic_string<char>::<anonymous>.std::__cxx11::basic_string<char>::<unnamed union>::_M_allocated_capacity' may be used uninitialized [-Werror=maybe-uninitialized]
1182 | return _M_is_local() ? size_type(_S_local_capacity)
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1183 | : _M_allocated_capacity;
| ~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /home/yamato99999/aur/mozc-ut/src/mozc-ut-git/src/protocol/BUILD.bazel:140:14 Compiling protocol/user_dictionary_storage.pb.cc failed: (Exit 1): gcc failed: error executing CppCompile command (from target @@com_google_protobuf//src/google/protobuf:protobuf) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 62 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Elapsed time: 218.061s, Critical Path: 11.59s
INFO: 833 processes: 403 internal, 430 linux-sandbox.
ERROR: Build did NOT complete successfully
==> エラー: build() で問題が発生しました。
中止...
こんな感じでメモリ16GBでも失敗する。
自分のPCがおかしいおま環?
とも疑う。
とりあえずmozc-utビルド、こんな感じで
失敗します。報告でした。 0336login:Penguin2024/05/13(月) 18:57:13.76ID:QN0Lo3oB
yay -G mozc
makepkg --syncdeps --rmdeps --cleanbuild
==> 作成完了: mozc 2.30.5448.102-1 (2024年05月13日 16時06分22秒)
==> Removing installed dependencies...
メモリー 7Gの環境でswap 2G 失敗 EndeavourOS
メモリー 7Gの環境でswap 10Gだと完走できるぽい Manjaro Testing
$ swapon --show
NAME TYPE SIZE USED PRIO
/dev/sdb6 partition 2G 0B 2
/media/ほげ/sys004/swapfile file 8G 7.5M 3
>>335
俺も16GB載せてるが2、3回に1度くらいの頻度で失敗するわ >>337
いえ。ユーザーのhomeディレクトリで
やってますよ。 環境によるビルドエラーというよりgccとコンパイルオプションの問題なのかな…?
g++のbasic_stringライブラリ側で内部変数'_M_allocated_capacity'が適切に初期化されてないぽいような
gcc側の問題ならclangにして回避するか-Werror=maybe-uninitializedオプションを外すとか
>-Werror=maybe-uninitialized
初期化されない場合、その警告をコンパイルエラーとして扱う指定
>cc1plus: all warnings being treated as errors
プリプロセッサかコンパイラあたりが警告をコンパイルエラーとして吐き出してる
いつもでやってんのofficalのビルド環境がubuntu24.04になったんだから
clangがデフォだよ
>>335
> 報告でした。
うおお偉い!まさか報告があるとは思わなかった。
まあ、インストールなんて所詮作業でしか無いから、何度やっても慣れてもほぼ無意味。
こういう引っかかったところで地道にデバッグして経験値を積み、Linuxのパワーレベル(戦闘力)を上げて行くのは正しいと思うぜ。
現状知らんので以下色々間違ってるかもしれんが、分かるところを書いておく。
まず状況を纏めると、
A. メモリ8GB, スワップ不明で、エラー(328)
B. メモリ8GB, スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(334)
C. メモリ16GB、スワップ不明で、sudo systemctl stop systemd-oomd して、エラー(335、後半のエラー内容は328と同じだが…)
でいいかな?出来ればA,B,Cにおけるスワップも教えて。
そしてもしスワップ無しで運用してて、万全を期したいなら、スワップ8-16GB程度を設定して試した方がいい。
(ただし結果は高い確率で変わらないので、面倒ならやらなくても問題ない)
> ttps://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/managing_storage_devices/recommended-system-swap-space_getting-started-with-swap#doc-wrapper さて上記からまず思うのは、
(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.
C(335)
INFO: Elapsed time: 218.061s, Critical Path: 11.59s
INFO: 833 processes: 403 internal, 430 linux-sandbox.
なので、多分AとCは違うところで止まってる。
最近のTurboBoostのマシンは知らんが、それでも同一マシンで流して1.5-3.4倍速になるとは思えない。
だから再度確認したほうがいいし、マジでメモリだけで1.5-3.4倍速になってるのなら普段から16GBで運用した方がいい。
(ついでに言うとB/Cはエラー前半見る限り同じ所で落ちてるが、こちらも2-3.4倍速になってる。
これも通常では考えられないので、前回のビルド結果が一部残ってたのではないかと思われるが、《configure時代なら make distclean 忘れ》
本当にメモリだけで倍速になってるのならマジで増設しとけではある)
そして、プロセス多すぎ。Arch知らんがMint20.3xfceだと何もしてなければ250個程度。
バックグラウンドで何か動かしてるのなら、当然それらもメモリ食ってるので、それらの状況次第で落ちる場所も変わってきてしまう。
この場合、>>338のようなことになり、精密なデバッグには不向き。
が、まあ、archはそういうもんならそれでいいが、なら最初からメモリ多めにしておくのが無難。 しかしまあここまでは所詮はデバッグ上の保険であって、これより以下が本命になる。
B,Cの前半見て分かるとおり、B,Cは明確にソースコード起因で落ちてる。
> [-Werror=maybe-uninitialized]
> cc1plus: all warnings being treated as errors
つまり、>>340の言うとおりで、
未初期化(っぽい)のを警告とし、cc1で警告は全てエラー扱いにしてるから落ちてる。
だからこれらを外してしまえば、少なくとも現在落ちてるところは通るようになる。
一般的な問題としては、
> cc1plus: all warnings being treated as errors
であり、そもそもC言語の文化では警告上等(=警告は無視するもの)であり、
警告が一つでもあればビルドを止める、なんて運用をしてるプロジェクトはほぼ無いはず。
このスレの連中なら、(まあ普段からしまくってるのかもしれんが)
nVidiaのプロプライエタリドライバのインストール時や、カーネルのアップデート時にビルドをしてるはず。
それらのログ見れば分かるが、警告なんて出まくりのはず。(でも当然動いてる)
ただまあこの文化はよろしい物ではないし、だからこそC++が出て来た、というのもある。
だから今回のケースでありそうなシナリオは、
1. ソースコード作成時には「全部の警告を出し(=-Wall)、プログラマは努力して全部の警告を消す、そうしないとビルドを通さない
2. そしてリリース時のgccバージョンでは、通る。(なお>>341の言うようにこの時点でclangならclangでやらないと駄目)
3. その後、gccのバージョンが上がり、以前よりもチェックが厳しくなり、新たに警告が出る様になった。
4. なので、334,335の通り、落ちるようになってしまった。 だから、解決策としては、
α:リリース時のgccバージョンでコンパイルする(通常はダウングレードすることになる)
β:オプションを調整して警告無視でコンパイルする
であり、archの場合はパッケージリリース時のgccバージョンが多分明確に分かるはずなので、
まずそれを調べ、
α-1:もしリリース時のgccバージョンよりも現在使用しているもののバージョンが低いのなら、アップデートしてビルドを試す。
α-2:ただし通常はダウングレードになってしまうと思われるので、こちらは面倒だからやらず、
β:オプションを調整してビルド、
になる。(つっても面倒ならgccが最新版であることを確認してβだけでいい)
最近C言語やって無いので以下は勘であり間違ってるかもしれんが、
-Wはマクロであり、通常は環境変数で指定する。
configure時代は大体 CCFLAGS=-Wall みたいな指定方法だったが、今は知らん。
ただ上記も「追加」であり、「削除」はどこにどう指定するのかは分からん。
もし、パッケージビルドといってもガワ被せただけで結局configureしてるのなら、多分configure自体かそこから呼ばれるbashスクリプト内で
export CCFLAGS=-Wall とかでデフォのオプションを指定してるはずだから、その辺を弄ることになる。
この場合はとりあえず grep 'maybe-uninitialized' * とかで探すことになる。
-Wall :全ての警告を表示しろ、の指示
-Wunused-but-set-parameter :変数に代入してるが使ってねえじゃん馬鹿ヤロー、と警告出せ、の指示
-Wallと被ってるから意味無い?まあそのとおりだが、この辺はダブっても問題ない、というノリ
そしてこの通り、全部の警告を出す=動作上は問題ないけどソースコードをもっときれいに出来るよね、も警告になる
だから自分でコード書くときは「全部の警告を出し、全部の警告を消す」ようにコードを整理するのが理想で、
多分このプロジェクトでもやってたんだろうが、その後gccのバージョンが上がり、新たな警告を出せるようになった場合は通らなくなる
-Werror=maybe-uninitialized:未初期化(かもしれない)変数を使用してたらエラーにしろ、の指示
ただ言っちゃ悪いがC言語の文法では未初期化は検出できないので、
(ある程度実績のあるプロジェクトなら)これは誤検出であり多分やりすぎなので切っていい)
なので、-Werror=maybe-uninitialized は勿論消すとして、
他に
> cc1plus: all warnings being treated as errors
を指示してるマクロがあるはずなので、それも消してビルドを試せばいい。
これについてはエラーログの
> (remaining 62 arguments skipped)
の部分をとりあえず全部表示させてコピペしてくれればそれっぽいの探せるけど。
が、これも面倒なら、ググッたら
> export CFLAGS="-Wno-error"
> export CXXFLAGS="-Wno-error"
> ttps://qiita.com/g_votte/items/36013cc54482acd608e4
> Sure, find where -Werror is set and remove that flag. Then warnings will be only warnings.
> ttps://stackoverflow.com/questions/11561261/how-can-i-compile-without-warnings-being-treated-as-errors
この辺参考にして。
ところで
> all warnings being treated as errors
ってどういう文法なんだこれ?
all warnings ARE being treated as errors
でAREが抜けてる気がするんだが、今更gccの連中が基本的英文法間違ってるわけ無いし、省略していいとかあったっけ?
(なお俺の英語はかなりいい加減なので間違ってたらご指摘よろしく)
単にbeing以下がwarningに形容詞的に掛かって全体としては名詞となっているだけかと
file not found(名詞) と file is not found(文) みたいな
意味としてはほぼ同じになりますか
>>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の違い聞けばいいだけだからそうしてみるわ。
回答ありがとう。他の人もサクッと分かればよろしく。 こんばんは。
mozc-utで苦しんでた者です。
ふと見ると、昨日付けでmozc-ut、fcitx5-mozc-ut
のバージョンが上がってました。
git pull して再ビルド。
gcc13を依存関係で要求されて入れました。
これでメモリ8GBでも、ビルド成功しました。★
皆さま、お力添ありがとうございました。
勉強になり、貴重な体験が出来ました。
しかしこういう問題に当たった時に
英文で、本家のフォーラムに報告して
作者に知らせて、一緒に解決して行ける様に
なると、本物のハッカー?なんでしょうね。
蛇足でした。
mozc 2.30.5448.102-2になってるね
-makedepends=('bazel' 'git' 'python')
+makedepends=('bazel' 'git' 'python' 'gcc13')
>>352
Aだとありとあらゆる警告がエラーと同義になるから意味合いが変わってくるんじゃね
treatが自動詞なのか受身なのか一目で判別しやすいようにつけてるんだとは思うけど、「現状の」という意味合いも一応兼ねてると思う >>355
スレチなので放置してたし、君が何を言ってるのかもよく分からんが、
聞いてはいるので結果を書いておく。
A:受動態文
B:名詞句
C:分詞構文(participle)または名詞句
でABC共に文法的には問題なし、意味は全部同じで、全ての警告がエラー、
ただしこの場合はC(=gcc出力)がなんとなくよいらしい