/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() で問題が発生しました。 中止...
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のプロプライエタリドライバのインストール時や、カーネルのアップデート時にビルドをしてるはず。 それらのログ見れば分かるが、警告なんて出まくりのはず。(でも当然動いてる)
> 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の連中が基本的英文法間違ってるわけ無いし、省略していいとかあったっけ? (なお俺の英語はかなりいい加減なので間違ってたらご指摘よろしく) 0350login:Penguin2024/05/14(火) 00:16:08.24ID:H9yYz+Wx 単にbeing以下がwarningに形容詞的に掛かって全体としては名詞となっているだけかと 0351login:Penguin2024/05/14(火) 01:29:54.68ID:Ppv6XzUu file not found(名詞) と file is not found(文) みたいな 意味としてはほぼ同じになりますか 0352login:Penguin2024/05/14(火) 01:31:32.20ID:x+9d/xHb>>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だと文法違反?)
エラーメッセージは交通標識や新聞の見出しのように文法的には正しくないけれど少ない語数で伝える場合があるらしい 例えば The file was not found. は file not found のように all warnings being treated as errors は All warnings ARE being treated as errors. から ARE が省略されているのかも 0370login:Penguin2024/06/10(月) 07:54:36.31ID:9H4wqqRG>>369 ネイティブ(であろうと思われる人達)に聞いた。 具体的には投稿者の国が表示される某匿名掲示板だが。