Compiling stuck at this stage: [ 13%] Built target mysys_objlib /usr/bin/x86_64-pc-linux-gnu-ranlib libmysqlgcs.a make[2]: Leaving directory '/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build' [ 13%] Built target mysqlgcs Interestingly: the load is negligible while portage no longer can proceed with the ebuild for some reason... In the mean time dev-db/mysql-8.0.21 compiles just fine! Reproducible: Always
me too :-(
please provide your emerge info
Created attachment 678178 [details] emerge-info.txt Note, that I'm using a hardened kernel, however don't see any log messages whatsoever.
Try with MAKEOPTS=-j1 and attach build.log on failure.
Created attachment 678196 [details] build.log [ 5%] Generating uca900_zh_tbls.cc, uca900_ja_tbls.cc cd /var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings && ../runtime_output_directory/uca9dump zh --in_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql/strings/lang_data/zh_hans.txt --out_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings/uca900_zh_tbls.cc ^Csandbox:stop caught signal 2 in pid 4 make[2]: *** [strings/CMakeFiles/strings_objlib.dir/build.make:83: strings/uca900_zh_tbls.cc] Interrupt make[1]: *** [CMakeFiles/Makefile2:2608: strings/CMakeFiles/strings_objlib.dir/all] Interrupt ps aux | grep portage root 2892 0.0 0.0 18956 9348 pts/2 S+ 17:51 0:00 /usr/bin/python3.7m /usr/lib/portage/python3.7/pid-ns-init 2893 root 2893 0.0 0.0 18956 9716 pts/3 Ss+ 17:51 0:00 /usr/bin/python3.7m /usr/lib/portage/python3.7/pid-ns-init 250 250 250 18 0,1,2 /usr/bin/sandbox [dev-db/mysql-8.0.22] sandbox /usr/lib/portage/python3.7/ebuild.sh compile portage 2899 0.0 0.0 2348 1664 pts/3 S+ 17:51 0:00 [dev-db/mysql-8.0.22] sandbox /usr/lib/portage/python3.7/ebuild.sh compile portage 2900 0.0 0.0 16816 8208 pts/3 S+ 17:51 0:00 /bin/bash /usr/lib/portage/python3.7/ebuild.sh compile portage 2916 0.0 0.0 16944 7196 pts/3 S+ 17:51 0:00 /bin/bash /usr/lib/portage/python3.7/ebuild.sh compile portage 2930 0.0 0.0 13336 4380 pts/3 S+ 17:51 0:00 /bin/bash /usr/lib/portage/python3.7/ebuild-helpers/emake VERBOSE=1 portage 2932 0.0 0.0 21096 4276 pts/3 S+ 17:51 0:00 make -j1 VERBOSE=1 portage 2938 0.0 0.0 21492 4732 pts/3 S+ 17:51 0:00 make -f CMakeFiles/Makefile2 all portage 3691 0.0 0.0 20964 4240 pts/3 S+ 17:52 0:00 make -f strings/CMakeFiles/strings_objlib.dir/build.make strings/CMakeFiles/strings_objlib.dir/depend portage 3693 0.0 0.0 10164 2168 pts/3 S+ 17:52 0:00 ../runtime_output_directory/uca9dump zh --in_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql/strings/lang_data/zh_hans.txt --out_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings/uca900_zh_tbls.cc root 32437 0.0 0.0 114216 103156 pts/2 S+ 17:50 0:01 /usr/bin/python3.7 -b /usr/lib/python-exec/python3.7/ebuild /usr/portage/dev-db/mysql/mysql-8.0.22.ebuild compile
I cannot reproduce. You are not cross compiling, right?
(In reply to Thomas Deutschmann from comment #6) > I cannot reproduce. You are not cross compiling, right? Absolutely not cross-compiling. Architecture: Haswell. I'm also not using ccache.
Anything useful from strace on the hanging process?
Created attachment 679371 [details] strace.log strace of: runtime_output_directory/uca9dump zh --in_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql/strings/lang_data/zh_hans.txt --out_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings/uca900_zh_tbls.cc
(In reply to Sam James from comment #8) > Anything useful from strace on the hanging process? Strangely enough: the command finishes successfully if I run it manually according to build.log. ( [ 5%] Generating uca900_zh_tbls.cc, uca900_ja_tbls.cc cd /var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings && ../runtime_output_directory/uca9dump zh --in_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql/strings/lang_data/zh_hans.txt --out_file=/var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings/uca900_zh_tbls.cc ) If I workaround it, later fails with: [ 6%] Linking CXX executable ../runtime_output_directory/conf_to_src cd /var/tmp/portage/dev-db/mysql-8.0.22/work/mysql-8.0.22_build/strings && /usr/bin/cmake -E cmake_link_script CMakeFiles/conf_to_src.dir/link.txt --verbose=1 /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -march=native -pipe -felide-constructors -fno-strict-aliasing -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Woverloaded-virtual -Wcast-qual -Wimplicit-fallthrough=2 -Wstringop-truncation -Wsuggest-override -Wlogical-op -DDBUG_OFF -DNDEBUG -fuse-ld=lld -Wl,-O1 -Wl,--as-needed -ljemalloc CMakeFiles/conf_to_src.dir/conf_to_src.cc.o -o ../runtime_output_directory/conf_to_src -lpthread ../archive_output_directory/libstrings.a ../archive_output_directory/libmysys.a ../archive_output_directory/libstrings.a ../archive_output_directory/libmysys.a ../archive_output_directory/libmytime.a -lpthread -lz /usr/lib64/libzstd.so -lm -lrt /usr/lib64/libssl.so /usr/lib64/libcrypto.so -ldl ld.lld: error: undefined symbol: MIN_JA_HAN_PAGE >>> referenced by ctype-uca.cc >>> ctype-uca.cc.o:(my_coll_init_uca) in archive ../archive_output_directory/libstrings.a ld.lld: error: undefined symbol: MAX_JA_HAN_PAGE >>> referenced by ctype-uca.cc >>> ctype-uca.cc.o:(my_coll_init_uca) in archive ../archive_output_directory/libstrings.a ld.lld: error: undefined symbol: ja_han_pages >>> referenced by ctype-uca.cc >>> ctype-uca.cc.o:(my_coll_init_uca) in archive ../archive_output_directory/libstrings.a collect2: error: ld returned 1 exit status So clang. I have no objection against clang if it works... What I cannot understand is that 8.0.21 compiles fine. There were only unrelevant changes in the strings directory. I don't really need this whole stuff (hans zh and ja)...
Recent discovery: compile halts if USE=jemalloc is enabled. So that the uca9dump binary produced and used during the build somehow gets stuck only if jemalloc is enabled... I disabled jemalloc for mysql as a workaround for now.
(In reply to Attila Tóth from comment #11) > Recent discovery: compile halts if USE=jemalloc is enabled. > So that the uca9dump binary produced and used during the build somehow gets > stuck only if jemalloc is enabled... > I disabled jemalloc for mysql as a workaround for now. There's a clue from other jemalloc related issues, that this may happen only with jemalloc built with USE=hardened enabled. I don't intend to test this with non-hardened jemalloc...
(In reply to Attila Tóth from comment #12) > (In reply to Attila Tóth from comment #11) > > Recent discovery: compile halts if USE=jemalloc is enabled. > > So that the uca9dump binary produced and used during the build somehow gets > > stuck only if jemalloc is enabled... > > I disabled jemalloc for mysql as a workaround for now. > > There's a clue from other jemalloc related issues, that this may happen only > with jemalloc built with USE=hardened enabled. I don't intend to test this > with non-hardened jemalloc... Update: jemalloc's hardened flag may be useless after all: https://bugs.gentoo.org/617518#c27 Either disable hardened for jemalloc or disable jemalloc for mysql to avoid this issue.
Closing as obsolete now that jemalloc[hardened] is gone: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f9f1a8c80671b4b1944226c84a5197183384a2ba
