On Sat, 2023 Nov 18 20:37-05:00, Andres Salomon wrote: > > I still haven't messed around with thinlto yet, but my primary concern > at this point is that various ARM build machines keep running out of > memory while building chromium. In particular, on armhf the arm-ubc-* > buildds run out of memory and kill the build,
On armhf, it's not possible to enable ThinLTO, because the final link requires more than 4 GB RAM. (I tried a full build in an armhf Docker container running under QEMU, on a system with 48 GB RAM, and still it failed.) I haven't tried i386, but presumably the same issue will occur there. (Is there a way to have official Debian packages be cross-compiled? This is a case where native compilation isn't ideal.) > as you can see on > https://buildd.debian.org/status/logs.php?pkg=chromium&arch=armhf There's something unrelated going on there, doubtful it's any kind of OOM at that point in the build. I think you'd have to peek at syslog to get an answer. Could be a hardware issue, for all the log shows. > I'm wondering if thinlto would possibly result in faster/less-memory- > intensive object (or bitcode or whatever) generation that might work > better on platforms with less memory? Do you know offhand how memory > usage of thinlto compares to what we (debian) do now (no LTO at all)? I'm not aware of LTO, in general, helping much with run-time memory usage. But it's supposed to make things run faster to some degree, and I figure that alone would be welcome on the less-beefy platforms. By the way, I've been meaning to write in with a related issue. ThinLTO currently fails on ppc64el, with this GN error: ----begin build log excerpt---- gn gen out/Release --args="clang_use_chrome_plugins=false ... use_thin_lto=true ..." ERROR at //build/config/compiler/BUILD.gn:696:5: Assertion failed. assert(use_lld, "LTO is only supported with lld") ^----- LTO is only supported with lld See //build/config/BUILDCONFIG.gn:333:3: which caused the file to be included. "//build/config/compiler:afdo", ^----------------------------- make[1]: *** [debian/rules:164: override_dh_auto_build-arch] Error 1 make[1]: Leaving directory '/<<PKGBUILDDIR>>' make: *** [debian/rules:127: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 ----end build log excerpt---- (Credit to Luiz Guzman @ Trisquel Linux for bringing this to my attention: https://github.com/ungoogled-software/ungoogled-chromium-debian/issues/334#issuecomment-1767888316) The issue comes down to this conditional in build/config/BUILDCONFIG.gn: # Set to true when compiling with the Clang compiler. is_clang = current_os != "linux" || (current_cpu != "s390x" && current_cpu != "s390" && current_cpu != "ppc64" && current_cpu != "ppc" && current_cpu != "mips" && current_cpu != "mips64" && current_cpu != "riscv64") The assumption underlying that logic is clearly incorrect in the Debian context. Perhaps we should just hard-code it to true. I don't know if there are other ramifications of is_clang=false in the ppc64el build. I sent a note to Tim about this, but never heard back.
