Created attachment 859454 [details] Full Build Log I have tried several use flag combinations and optimization levels (even -O0). Also tried building with MAKEOPTS="-j1". It builds successfully in every case except "pgo" use flag enabled. I just haven't tried X and PGO together because I use Wayland. My system is completely functional and every package is updated as for now. I tried changing the version of wlroots package. Tried to change Rust version. Compile python 3.10 in addition to 3.11. Also tried compiling Rust with and without system-llvm use flag. I have compiled the whole system to amd64 and also compiled the whole system to ~amd64 testing and even did a fresh Gentoo install and tried there, just by following the handbook. The problem is the same for other versions of Firefox or Librewolf. Nothing changes the results. In every case, it builds with clang + lto and other flags but not with PGO. I have compiled all of Clang toolchain and Rust with Clang and with these use flags: sys-devel/clang extra static-analyzer sys-devel/clang-runtime compiler-rt openmp sanitize sys-devel/clang-toolchain-symlinks native-symlinks sys-devel/llvm binutils-plugin libffi ncurses sys-devel/llvm-toolchain-symlinks native-symlinks sys-devel/lld sys-devel/lld-toolchain-symlinks native-symlinks sys-libs/compiler-rt clang sys-libs/compiler-rt-sanitizers asan cfi clang dfsan gwp-asan hwasan libfuzzer lsan memprof msan orc profile safestack scudo tsan ubsan xray sys-devel/clang-common default-compiler-rt default-lld sys-devel/llvm-common sys-devel/llvmgold dev-lang/rust system-llvm You can access the full build log from the attached file and below is "emerge --info" + my clang environment (as I stated, I also tried with all optimization flags disabled, including ldflags and rustflags, together with MAKEOPTS="-j1": $cat /etc/portage/env/compiler-clang CC="clang" CXX="clang++" LD="ld.lld" AR="llvm-ar" NM="llvm-nm" RANLIB="llvm-ranlib" STRIP="llvm-strip" OBJCOPY="llvm-objcopy" OBJDUMP="llvm-objdump" COMMON_FLAGS="-O3 -march=native -pipe -fomit-frame-pointer -flto" CFLAGS="${COMMON_FLAGS}" CXXFLAGS="${COMMON_FLAGS} -stdlib=libstdc++" FCFLAGS="${COMMON_FLAGS}" FFLAGS="${COMMON_FLAGS}" LDFLAGS="-stdlib=libstdc++ -fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind -Wl,-O3 -Wl,--lto-O3 -Wl,--as-needed" RUSTFLAGS="-C debuginfo=0 -C target-cpu=native -C opt-level=3"
Created attachment 859455 [details] emerge --info
This error is usually caused by wrongly configured locale settings but I don't see anything weird with those. It could also be related to ant configuration but I don't remember the specifics. Have you perhaps done something ant/locale related lately?
I have used these commands exactly, to configure locales during setup. My system is not even a week old. I directly downloaded the newest tar.gz for nomultilib 17.1 profile: # After chrooting source /etc/profile export PS1="(chroot) ${PS1}" # Syncing emerge-webrsync emerge-sync # Setting Timezone echo "Europe/Istanbul" > /etc/timezone emerge --config sys-libs/timezone-data # Setting Locale sed -i "s/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/g" /etc/locale.gen locale-gen eselect locale set en_US.utf8 env-update && source /etc/profile && export PS1="(chroot) ${PS1}" # Complete system rebuild and update emerge --quiet-build --update --complete-graph --deep -e @world # Hostname sed -i "s/hostname=.*/hostname=\"myusername\"/g" /etc/conf.d/hostname # Hosts sed -i 's/127.0.0.1.*/127.0.0.1\tmyusername\tlocalhost/g' /etc/hosts sed -i 's/::1.*/::1\t\tmyusername\tlocalhost/g' /etc/hosts # OpenRC Config sed -i 's/#rc_parallel=\".*\"/rc_parallel=\"YES\"/g' /etc/rc.conf sed -i 's/#unicode=\".*\"/unicode=\"YES\"/g' /etc/rc.conf sed -i 's/clock=.*/clock=\"local\"/g' /etc/conf.d/hwclock Now, I also checked, en_US.utf8 is properly selected, I don't use any other locale. Maybe I need some extra kernel settings? Or NLS use flag? I see "hwclock fail" when I am booting but I don't have any problems with clock. It's correct. So I didn't mind that error. What do you mean by ant? What is it? Related kernel settings I have: NLS_DEFAULT utf8 NLS_CODEPAGE_437 y NLS_ASCI y NLS_ISO8859_1 y NLS_UTF8 y UNICODE y
(In reply to Joonas Niilola from comment #2) > This error is usually caused by wrongly configured locale settings but I > don't see anything weird with those. It could also be related to ant > configuration but I don't remember the specifics. Have you perhaps done > something ant/locale related lately? Please inform if I need to provide more information. Any kind of recommendation can also help. I can even rebuild the system.
Hmm I was able to build firefox-111.0 successfully with your USE flags. It does look like pgo is failing the build after all, ---------- 00:15:38.456 [types/wlr_compositor.c:688] New wlr_surface 0x419b40 (res 0x419ea0) 00:15:38.456 [types/wlr_compositor.c:688] New wlr_surface 0x419fc0 (res 0x41a320) console.warn: services.settings: Ignoring preference override of remote settings server console.warn: services.settings: Allow by setting MOZ_REMOTE_SETTINGS_DEVTOOLS=1 in the environment 00:15:39.012 [types/wlr_compositor.c:688] New wlr_surface 0x41a630 (res 0x41a990) 00:15:39.012 [types/wlr_compositor.c:688] New wlr_surface 0x41a990 (res 0x41acf0) libEGL warning: failed to get driver name for fd 0 libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to get driver name for fd 0 00:15:39.098 [types/wlr_compositor.c:688] New wlr_surface 0x41b260 (res 0x41b5c0) 00:15:39.341 [types/wlr_compositor.c:688] New wlr_surface 0x41c440 (res 0x41c7a0) 00:15:39.341 [types/wlr_compositor.c:688] New wlr_surface 0x41c8c0 (res 0x41cc20) 00:15:39.401 [types/wlr_compositor.c:688] New wlr_surface 0x426a90 (res 0x426df0) 00:15:39.401 [types/wlr_compositor.c:688] New wlr_surface 0x426e80 (res 0x41b5c0) 00:15:39.410 [types/wlr_compositor.c:688] New wlr_surface 0x427d90 (res 0x4280f0) 00:15:39.410 [types/wlr_compositor.c:688] New wlr_surface 0x428210 (res 0x428570) 00:15:39.431 [types/wlr_compositor.c:688] New wlr_surface 0x428600 (res 0x428960) 00:15:39.497 [types/xdg_shell/wlr_xdg_surface.c:388] new xdg_surface 0x4289f0 (res 0x428b20) 00:15:39.498 [types/wlr_compositor.c:688] New wlr_surface 0x429650 (res 0x4299b0) Exiting due to channel error. Exiting due to channel error. Firefox exited with code -11 during profile initialization Error running mach: ['build', '--verbose'] The error occurred in code that was called by the mach command. This is either a bug in the called code itself or in the way that mach is calling it. You can invoke |./mach busted| to check if this issue is already on file. If it isn't, please use |./mach busted file build| to report it. If |./mach busted| is misbehaving, you can also inspect the dependencies of bug 1543241. If filing a bug, please include the full output of mach, including this error message. The details of the failure are as follows: subprocess.CalledProcessError: Command '['/var/tmp/portage/www-client/firefox-111.0/work/firefox_build/_virtualenvs/build/bin/python', '/var/tmp/portage/www-client/firefox-111.0/work/firefox-111.0/build/pgo/profileserver.py']' returned non-zero exit status 245. File "/var/tmp/portage/www-client/firefox-111.0/work/firefox-111.0/python/mozbuild/mozbuild/build_commands.py", line 215, in build subprocess.check_call(pgo_cmd, cwd=instr.topobjdir, env=pgo_env) File "/usr/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) >>> Source compiled. ---------- but not stopping the build for some reason. Probably a bug in our virtwl() implementation. I also see: ---------- >>> Compiling source in /var/tmp/portage/www-client/firefox-111.0/work/firefox-111.0 ... 00:00:00.000 [backend/backend.c:315] Loading user-specified backends due to WLR_BACKENDS: headless 00:00:00.000 [backend/headless/backend.c:68] Creating headless backend 00:00:00.000 [util/env.c:9] Loading WLR_NO_HARDWARE_CURSORS option: 1 00:00:00.000 [types/output/output.c:366] WLR_NO_HARDWARE_CURSORS set, forcing software cursors 00:00:00.004 [render/wlr_renderer.c:339] Opening DRM render node '/dev/dri/renderD128' 00:00:00.004 [render/wlr_renderer.c:342] Failed to open '/dev/dri/renderD128': Permission denied 00:00:00.004 [render/wlr_renderer.c:245] Cannot create GLES2 renderer: no DRM FD available. Skipping! 00:00:00.004 [render/pixman/renderer.c:529] Creating pixman renderer 00:00:00.004 [render/allocator/allocator.c:121] Trying to create shm allocator 00:00:00.004 [render/allocator/shm.c:118] Created shm allocator 00:00:00.008 [xcursor/wlr_xcursor.c:243] Loaded cursor theme 'default' at size 24 (26 available cursors) 00:00:00.008 [backend/headless/backend.c:16] Starting headless backend 00:00:00.008 [tinywl/tinywl.c:1000] Running Wayland compositor on WAYLAND_DISPLAY=wayland-0 00:00:00.008 [types/output/swapchain.c:28] Choosing primary buffer format XR24 (0x34325258) for output 'HEADLESS-1' 00:00:00.008 [types/output/swapchain.c:87] Testing swapchain for output 'HEADLESS-1' 00:00:00.008 [render/swapchain.c:107] Allocating new swapchain buffer 00:00:00.008 [render/pixman/renderer.c:120] Created pixman buffer 1280x720 ---------- early on, which is weird. The ebuild says: # TODO: don't run addpredict in utility function. WLR_RENDERER=pixman doesn't work so maybe that's your issue? So just some findings here, no idea how to fix it currently. I'm also aware some updates to virtualx.eclass last august broke pgo for some people, https://gitweb.gentoo.org/repo/gentoo.git/log/eclass/virtualx.eclass but they never followed up if they solved it or not.
(In reply to Joonas Niilola from comment #5) > Hmm I was able to build firefox-111.0 successfully with your USE flags. It > does look like pgo is failing the build after all, > > ---------- Thanks a lot for taking your time :) Do you think it can be fixed with regular updates by itself in the future? The august update didn't affect me. I built Firefox with Clang + LTO + PGO + Wayland use flags successfully on the last February. Somehow, it fails building now.
(In reply to Joonas Niilola from comment #5) > Hmm I was able to build firefox-111.0 successfully with your USE flags. It > does look like pgo is failing the build after all, > I have solved the problem by also adding the X use flag along with wayland use flag. But that change pulls lots of unwanted dependencies. Would there be any other fixes with this information?
To me from the errors it somehow looks like your graphical session is a bit wonky, or not supported by the virtwl() function in the ebuild. With +X it uses virtx, a different implementation, to build with pgo. So the virtwl may be buggy. Or rather, is buggy because it doesn't even exit on error. But I was able to build firefox -X +lto +pgo +wayland so there's that too... I really don't know, I'm hoping upstream somehow broke wayland-only build, but I don't see anyone reporting this upstream either so can't be sure. One thing that brings "hope" is that you're using nvidia, and 112 should have some nvidia fixes included, to my understanding, driver version 530. I guess Nvidia+wayland is still a bit unstable combination.
(In reply to Joonas Niilola from comment #8) > To me from the errors it somehow looks like your graphical session is a bit > wonky, or not supported by the virtwl() function in the ebuild. I use Hyprland compositor with its own wlroots (it doesn't use the upstream). But packages such as Firefox also pull an external wlroots so I am not sure if that affects it. I start my session with these variables: export _JAVA_AWT_WM_NONREPARENTING=1 export LIBVA_DRIVER_NAME=nvidia export GBM_BACKEND=nvidia-drm export __GLX_VENDOR_LIBRARY_NAME=nvidia export WLR_NO_HARDWARE_CURSORS=1 export XDG_RUNTIME_DIR="/tmp/hyprland" export SDL_VIDEODRIVER=wayland export QT_SCREEN_SCALE_FACTORS="1;1" export XCURSOR_SIZE=18 export MOZ_ENABLE_WAYLAND=1 export QT_QPA_PLATFORM=wayland export ANV_QUEUE_THREAD_DISABLE=1 export XDG_SESSION_TYPE=wayland export XDG_CURRENT_DESKTOP=Hyprland export XDG_SESSION_DESKTOP=Hyprland export MOZ_DBUS_REMOTE=1 mkdir -p $XDG_RUNTIME_DIR chmod 0700 $XDG_RUNTIME_DIR exec dbus-launch Hyprland
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8483d1122b4c093c8a8886de70774332c81b626a commit 8483d1122b4c093c8a8886de70774332c81b626a Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2023-04-11 05:11:03 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-04-11 05:12:58 +0000 www-client/firefox: add 112.0 - include dont-crash-on-wayland-log-handler.patch from upstream bug #1826583, - remove "accessibility.typeaheadfind" from our default prefs. Bug: https://bugs.gentoo.org/902149 Bug: https://bugs.gentoo.org/903710 Bug: https://bugs.gentoo.org/901353 Bug: https://bugs.gentoo.org/904072 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 101 ++ www-client/firefox/files/gentoo-default-prefs.js | 1 - www-client/firefox/firefox-112.0.ebuild | 1379 ++++++++++++++++++++++ 3 files changed, 1480 insertions(+), 1 deletion(-)
(In reply to Larry the Git Cow from comment #10) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=8483d1122b4c093c8a8886de70774332c81b626a > I have now confirmed that this change has fixed the issue completely for me with following use flags and dependencies: www-client/firefox-112.0 -* wayland pgo lto clang dbus eme-free openh264 system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-png system-webp FLAGS="-march=native -O3 -pipe -fomit-frame-pointer -flto" RUSTFLAGS="-C debuginfo=0 -C target-cpu=native -C opt-level=3" sys-kernel/gentoo-sources-6.2.11 x11-drivers/nvidia-drivers-530.41.03 media-libs/mesa-23.0.2-r1 gui-libs/wlroots-0.16.2 Thanks again!
Thanks for confirming! Glad to see upstream figured it out.
