=www-client/ungoogled-chromium-96.0.4664.45-r1: fails to compile

[0xC0ncord]

Looks like the newest ebuild is failing to build for me.

FAILED: obj/media/gpu/vaapi/libva_stubs/va_stubs.o 
clang++ -MMD -MF obj/media/gpu/vaapi/libva_stubs/va_stubs.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DUSE_X11=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -Igen/media/gpu/vaapi -I../.. -Igen -I../../third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen/shim_headers/zlib_shim -I../../third_party/abseil-cpp -I../../third_party/boringssl/src/include -I../../third_party/protobuf/src -Igen/protoc_out -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -flto=thin -fsplit-lto-unit -fwhole-program-vtables -no-canonical-prefixes -Wimplicit-fallthrough -Wunreachable-code-aggressive -Wthread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-psabi -Wno-ignored-pragma-optimize -Wno-builtin-assume-aligned-alignment -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-bitwise-instead-of-logical -fno-omit-frame-pointer -ftrivial-auto-var-init=pattern -fprofile-instr-use=../../chrome/build/pgo_profiles/chrome-linux-4664-1636557077-6e390f4e505916531ca2ab0c895d5903ab4d88a9.profdata -Wno-profile-instr-unprofiled -Wno-profile-instr-out-of-date -Wno-backend-plugin -fsanitize=cfi-vcall -fsanitize-ignorelist=../../tools/cfi/ignores.txt -fsanitize=cfi-derived-cast -fsanitize=cfi-unrelated-cast -fsanitize=cfi-icall -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/libffi/include -DPROTOBUF_ALLOW_DEPRECATED=1 -std=c++14 -fno-trigraphs -Wno-trigraphs -fno-exceptions -fno-rtti -fvisibility-inlines-hidden  -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -march=znver2 -mtune=znver2 -O3 -pipe -fomit-frame-pointer -fpie -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fstack-clash-protection -flto=thin -stdlib=libc++ -fPIC -flax-vector-conversions=all -Wno-unknown-warning-option -Wno-builtin-macro-redefined -c gen/media/gpu/vaapi/va_stubs.cc -o obj/media/gpu/vaapi/libva_stubs/va_stubs.o
gen/media/gpu/vaapi/va_stubs.cc:15:10: fatal error: 'media/gpu/buildflags.h' file not found
#include "media/gpu/buildflags.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

# emerge -pqv ungoogled-chromium
[ebuild     U ] www-client/ungoogled-chromium-96.0.4664.45-r1 [95.0.4638.69-r1] USE="cfi clang convert-dict cups custom-cflags hangouts js-type-check official optimize-thinlto optimize-webui partition pgo proprietary-codecs pulseaudio screencast (selinux) suid tcmalloc thinlto vaapi vdpau wayland -debug -enable-driver -headless -kerberos -system-ffmpeg -system-harfbuzz -system-icu -system-jsoncpp -system-libevent -system-libvpx -system-openh264 -system-openjpeg -system-re2 -widevine" L10N="-am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW" 

I suspect this might be somehow related to #108

[PF4Public]

I've removed that patch as it is no longer needed.

[0xC0ncord]

Hmm. What then provides media/gpu/buildflags.h? Maybe I'm missing a dependency?

[PF4Public]

Interesting. I'm building with vaapi only right now and I see media/gpu/buildflags.h in out/Release/gen… and its contents is as follows:

// Generated by build/write_buildflag_header.py
// From "//media/gpu:buildflags"

#ifndef MEDIA_GPU_BUILDFLAGS_H_
#define MEDIA_GPU_BUILDFLAGS_H_

#include "build/buildflag.h"

#define BUILDFLAG_INTERNAL_USE_VAAPI() (1)
#define BUILDFLAG_INTERNAL_USE_VAAPI_IMAGE_CODECS() (0)
#define BUILDFLAG_INTERNAL_USE_V4L2_CODEC() (0)
#define BUILDFLAG_INTERNAL_USE_LIBV4L2() (0)
#define BUILDFLAG_INTERNAL_USE_VAAPI_X11() (1)

#endif  // MEDIA_GPU_BUILDFLAGS_H_

Something prevents the generation of this file. Maybe wayland?

Probbaly vdpau patch needs to be further improved? No idea.

@gringus Did you build with vdpau successfully?

[0xC0ncord]

Indeed I do not see that file in the build directory on my system. Let me see if I can find out if a USE flag like wayland as you said is preventing it from being generated.

[0xC0ncord]

It looks like USE=wayland is what may be causing this. I have disabled wayland (and screencast) and I now see the generated file.

[PF4Public]

Could be that Chromium does not support that under wayland…

[0xC0ncord]

Could be that Chromium does not support that under wayland…

Potentially, but I have my doubts. I am trying this out on a second machine and so far it looks like it is building... If the build succeeds, it should be done in another hour or two. We will see.

[gringus]

I built it with vaapi vdpau flags but without wayland (I also had to add the patch from https://bugs.gentoo.org/823857)

[0xC0ncord]

Could be that Chromium does not support that under wayland…

Potentially, but I have my doubts. I am trying this out on a second machine and so far it looks like it is building... If the build succeeds, it should be done in another hour or two. We will see.

Well this is really weird... On my secondary machine, I have USE="wayland vaapi vdpau" and was able to emerge ungoogled-chromium without a problem. I did still apply the patch from https://bugs.gentoo.org/823857 though.

www-client/ungoogled-chromium-96.0.4664.45-r1::pf4public was built with the following:
USE="cfi clang convert-dict cups custom-cflags hangouts js-type-check official optimize-thinlto optimize-webui partition pgo proprietary-codecs pulseaudio screencast (selinux) suid tcmalloc thinlto vaapi vdpau wayland -debug -enable-driver -headless -kerberos -system-ffmpeg -system-harfbuzz -system-icu -system-jsoncpp -system-libevent -system-libvpx -system-openh264 -system-openjpeg -system-re2 -widevine" L10N="-am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW"
CFLAGS="-march=znver2 -mtune=znver2 -O3 -pipe -fomit-frame-pointer -fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fstack-clash-protection -flto=thin -fPIC -Wno-unknown-warning-option -Wno-builtin-macro-redefined"
CXXFLAGS="-march=znver2 -mtune=znver2 -O3 -pipe -fomit-frame-pointer -fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fstack-clash-protection -flto=thin -stdlib=libc++ -fPIC -flax-vector-conversions=all -Wno-unknown-warning-option -Wno-builtin-macro-redefined"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-S -Wl,-z,now -Wl,-z,relro -fuse-ld=lld -Wl,-unwindlib=libunwind -lhardened_malloc -Wl,--thinlto-jobs=17"

[PF4Public]

On my secondary machine, I have USE="wayland vaapi vdpau" and was able to emerge ungoogled-chromium without a problem.

What differs them?

[0xC0ncord]

On my secondary machine, I have USE="wayland vaapi vdpau" and was able to emerge ungoogled-chromium without a problem.

What differs them?

As far as the flags used to build Chromium, nothing.

[gringus]

Package versions?

[0xC0ncord]

@gringus Which packages do you mean? Assuming you mean ungoogled-chromium itself, 96.0.4664.45-r1 for both. I am not using any of the system-* USE flags.

[gringus]

I meant other dependent packages (eg. glibc etc.) which could be on different version. Some could be buggy and cause issues.

[0xC0ncord]

So I managed to solve this somehow, but unfortunately I'm not sure what it was. I had 2 versions of LLVM installed simultaneously, and it seems that lld was wanting to link to libraries belonging to a different LLVM version. After removing Clang/LLVM 12 and rebuilding the entire toolchain, the issue went away.

Very weird. Thanks for the support.

[logrusx]

Trying to deal with #118 I hit this. This is what's failing for me:

[ebuild R ] www-client/ungoogled-chromium-96.0.4664.45-r1::pf4public USE="clang convert-dict cups hangouts js-type-check official optimize-thinlto optimize-webui partition proprietary-codecs pulseaudio screencast -system-ffmpeg system-harfbuzz system-icu thinlto vaapi wayland -cfi -custom-cflags -debug -enable-driver -headless -kerberos -pgo (-selinux) -suid -system-jsoncpp -system-libevent -system-libvpx -system-openh264 -system-openjpeg -system-re2 -tcmalloc -vdpau -widevine"

Can I do/test something to help with this too?

[PF4Public]

@logrusx Your issue is obviously different, please open a separate issue and provide full build log!

[logrusx]

I'm pretty sure it's the same issue, as the error is the same. I'll provide the build log as soon as the current build finishes or breaks, I apologize for not doing that first place. It should be ready shortly.

[0xC0ncord]

I'm pretty sure it's the same issue, as the error is the same. I'll provide the build log as soon as the current build finishes or breaks, I apologize for not doing that first place. It should be ready shortly.

This is what I did to resolve my original issue:

I uninstalled all other versions of Clang, LLVM, and dependencies except for versions 13.0.0. That includes libcxx, libcxxabi, lld, and also llvmgold. I rebuilt my entire Clang/LLVM toolchain using gcc and without LTO enabled and made sure that only versions 13.0.0 were being pulled in. After that, I rebuilt the entire toolchain again but this time using Clang and LTO. Finally, I emerged ungoogled-chromium after this rebuild and did not have the problem anymore.

I also went as far as to mask all of these packages versions lower than 13.0.0 just to be sure.

Hopefully that helps.

[logrusx]

@0xC0ncord thanks for your responce!

This is a new installation and it has had nothing older than clang 13 and gcc 11.2.

Is I mentioned above, I was trying to solve another issue by matching the use flags to original chromium and disabling the ones not present for it. This lead me to the current issue, but I was too quick to start eliminating use flag changes and didn't grab the build log. It seems it was -system-ffmpeg as I took the path of eliminating the changes I made to match the original source and when I turned back on the system ffmpeg, the build passed way over the place it broke before. The current build is almost finished and as soon as it finishes I'll disable system-ffmpeg again to extract build log.

In the mean time, could you please check if it's enabled for you? Regards

[0xC0ncord]

In the mean time, could you please check if it's enabled for you? Regards

I currently have all system-* flags disabled for my builds.

[logrusx]

@0xC0ncord what about ccache, did you use it?

[0xC0ncord]

@0xC0ncord what about ccache, did you use it?

No, I didn't.

[logrusx]

It looks like ccache with either system ffmpeg or libevent is the culprit with my issue. Are you sure you couldn't have forgotten ccache enabled? I'm asking that, because recompiling your compiler would effectively invalidate the cache(if explicit measures to prevent it aren't taken) and the first pass would be cache building only.

[0xC0ncord]

I'm sure because I never enabled ccache in the first place. I think what caused the issue for you is definitely different from what caused it for me. Ultimately I think somehow when I had this issue my clang toolchain was actually completely broken, as some packages outright refused to compile about the same time as this, but I didn't think those issues were related at the time.

[logrusx]

Ok, it was worth digging into it, because now at least somebody could find out that they might need to disable ccache, just by searching on the Internet and not needing to find it out the hard way. Thanks for your support! Regards

[0xC0ncord]

Interestingly I just had this exact same issue again but on a different machine. What seems to be the real fix is just to re-emerge mesa. After that the issue went away.

[logrusx]

Reemerge mesa didn't help in my case. Here's the build log https://drive.google.com/file/d/1_nBnHqFu_HJ1sGz07lCF5viaevksosMG/view?usp=sharing

[logrusx]

@0xC0ncord could you please share your mesa use flags?

[0xC0ncord]

I have:

media-libs/mesa-22.0.0_rc2::gentoo was built with the following:
USE="X gles2 llvm (selinux) vaapi vdpau vulkan wayland xvmc zstd -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa -test -unwind -valgrind -vulkan-overlay -xa -zink" CPU_FLAGS_X86="sse2" VIDEO_CARDS="radeon radeonsi (-freedreno) -intel (-lima) -nouveau (-panfrost) -r300 -r600 (-v3d) (-vc4) -virgl (-vivante) -vmware"

[logrusx]

@0xC0ncord very quickly, thanks! p.s. I see your VIDEO_CARDS only contain radeon and radeonsi, don't you get the following?

Running pre-merge checks for media-libs/mesa-21.3.5

• Ignoring USE=xvmc since VIDEO_CARDS does not contain r600 or nouveau

[0xC0ncord]

Yes, I just removed that USE flag in fact. :)

[logrusx]

Disabling system ffmpeg seems to have bypassed the problematic code, I don't know why. But you still hit it with all system-* use flags disabled, if I remember correctly. So this is a complex issue.