I'd love to give a longer description, but the build.log just says "FAILED:" followed by a long command line. This is compiling with clang (which is configured OK and compiled loads of kde-frameworks earlier in the same "emerge --update --deep --changed-use @world". If I revert to gcc, it adds "Segmentation fault", which might be useful. emerge -pvq kdoctools gives: [ebuild U ] kde-frameworks/kdoctools-5.110.0 [5.108.0] USE="nls -debug -test" I'll attach emerge --info and the build log Reproducible: Always Steps to Reproduce: 1. emerge --update --deep --changed-use @world or emerge --resume 2. Wait for the boom
Created attachment 871838 [details] emerge --info kde-frameworks/kdoctools
Created attachment 871839 [details] build.log
Oh, and I forgot to mention, everything else in the emerge --update run is stalled, as kdoctools is a dependency, and --skip-first doesn't work for the same reason.
Created attachment 871840 [details] build.log, but this time single-threaded, which may help
Sorry for the stream of conciousness, but some more info: If I reproduce the failing step in the build directory, it's a Segmentation fault thrown by bin/meinproc5. It's independent of any parameters passed (indeed, said fault comes with no parameters). It is of course built earlier in the same emerge, step [19] if I read it correctly. I wondered if mold broke building meinproc5, but swapping to lld makes no change.
I tried various mixtures of lld, mod, the default linker, and gcc and clang, applied to kdoctools, and none got round the segfault. Now I've reverted all my kde- stuff to the versions before my latest "emerge --update" run (thankfully I have a binpkg host), so I can retry without mold. Running "emerge --update", with LD-FLAGS="-fuse-ld=lld" and clang - i.e. without mold at all - and the emerges run OK, including kdoctools! So it appears mold-2.2.0 built something earlier in the kde food chain that caused the segfault. Presumably a bad kde library used by meinproc5 built by and later used within kdoctools. If my gdb skills were better, I might have been able to work out where, but as it is, I'm happy to have bypassed the problem. I'll see if I can find how to report it upstream to the mold devs; if so, I'll add the bug report in a later comment.
OK, I got past kdoctools, but ghostscript-gpl fails to emerge, and its build log is full of segfaults. This emerge was with fuse-ld=lld, so it makes me think mold built some other libraries badly - I'll have to try reverting more stuff to before my last emerge --update. This is with mold-2.2.0, which is in testing. I started playings some time ago with mold-1.0, and hadn't noticed it moving into stable. So possibly 2.2.0 is bad. If I can automate reverting without the hassle of having to use my backup disk, I may test to see if it works with mold-2.1.0, otherwise I'll apply some mold-killer and revert to lld!
Yup, rebuilding everything with lld instead of mold cured the segfaults in ghostscript-gpl as well, so it's definitely mold - I don't think I changed anything else. My previous versions of both ghostscript-gpl and kdoctools were made some time back - I'm not sure if they were linked with mold, in which case it was before mold-2.0.0, but equally possibly lld.
Thanks. I think will need some ideally small package which fails with mold (in an ideal world its test suite would fail rather than another package using it, but it's ok if some call to it is needed instead). Maybe try in a chroot (can unpack it to just /tmp or some other location) and build some packages selectively with mold?
kdoctools has minimal dependencies: > * dependency graph for kde-frameworks/kdoctools-5.110.0 > `-- kde-frameworks/kdoctools-5.110.0 ~amd64 > `-- app-text/docbook-xml-dtd-4.5-r2 (app-text/docbook-xml-dtd) ~amd64 > `-- app-text/docbook-xsl-stylesheets-1.79.1-r4 (app-text/docbook-xsl-stylesheets) ~amd64 > `-- app-text/sgml-common-0.6.3-r7 (app-text/sgml-common) ~amd64 > `-- dev-libs/libxml2-2.11.5 (dev-libs/libxml2) ~amd64 > `-- dev-libs/libxslt-1.1.38 (dev-libs/libxslt) ~amd64 > `-- kde-frameworks/karchive-5.110.0 (=kde-frameworks/karchive-5.110*) ~amd64 > `-- dev-qt/qttest-5.15.10 (dev-qt/qttest) ~amd64 > `-- dev-qt/qtcore-5.15.10-r2 (dev-qt/qtcore) amd64 > `-- kde-frameworks/kf-env-5 (>=kde-frameworks/kf-env-4) amd64 > `-- dev-lang/perl-5.38.0-r1 (dev-lang/perl) ~amd64 > `-- dev-perl/URI-5.210.0 (dev-perl/URI) ~amd64 > `-- kde-frameworks/ki18n-5.110.0 (>=kde-frameworks/ki18n-5.110) ~amd64 > `-- dev-util/ninja-1.11.1-r2 (>=dev-util/ninja-1.8.2) amd64 > `-- dev-util/cmake-3.27.6-r1 (>=dev-util/cmake-3.20.5) ~amd64 > `-- dev-libs/libpcre2-10.42-r1 (dev-libs/libpcre2) amd64 > `-- kde-frameworks/extra-cmake-modules-5.110.0 (>=kde-frameworks/extra-cmake-modules-5.110) ~amd64 > [ kde-frameworks/kdoctools-5.110.0 stats: packages (17), max depth (1) ] and meinproc5 looks like this: > meinproc5 => /usr/bin/meinproc5 (interpreter => /lib64/ld-linux-x86-64.so.2) > libxml2.so.2 => /usr/lib64/libxml2.so.2 > libz.so.1 => /lib64/libz.so.1 > liblzma.so.5 => /lib64/liblzma.so.5 > libicuuc.so.73 => /usr/lib64/libicuuc.so.73 > libicudata.so.73 => /usr/lib64/libicudata.so.73 > libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1 > ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 > libm.so.6 => /lib64/libm.so.6 > libxslt.so.1 => /usr/lib64/libxslt.so.1 > libexslt.so.0 => /usr/lib64/libexslt.so.0 > libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 > libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 > libKF5Archive.so.5 => /usr/lib64/libKF5Archive.so.5 > libbz2.so.1 => /lib64/libbz2.so.1 > libzstd.so.1 => /lib64/libzstd.so.1 > libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 > libdouble-conversion.so.3 => /usr/lib64/libdouble-conversion.so.3 > libicui18n.so.73 => /usr/lib64/libicui18n.so.73 > libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0 > libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 > libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 > libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 > libc.so.6 => /lib64/libc.so.6
