I cannot install the rawhide-built chromium into F33 without bringing glibc from rawhide with me:

[spot@localhost ~]$ sudo rpm -Uvh chromium-common-87.0.4280.88-1.fc34.x86_64.rpm chromium-87.0.4280.88-1.fc34.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.33)(64bit) is needed by chromium-common-87.0.4280.88-1.fc34.x86_64
libc.so.6(GLIBC_2.33)(64bit) is needed by chromium-87.0.4280.88-1.fc34.x86_64

When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance (glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86, glibc-langpack-en), then install the rawhide built chromium, it exhibits the same missing strings bug.

~spot



On Thu, Dec 17, 2020 at 11:29 AM Robbie Harwood <rharwood@redhat.com> wrote:
Tom Callaway <spotrh@gmail.com> writes:

> Okay, this one has me stumped. Any chromium package I build through rawhide
> refuses to render most of the strings.
>
> At first, I thought this was gcc 11, but then I noticed that the first
> build with this problem was built before GCC 11 landed in rawhide (the
> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> must be due to a newer system component that Chromium uses dynamically, but
> I was able to disprove that by installing the Fedora 33 build (same
> version-release) into a Rawhide VM, and it works fine. Google Chrome also
> works fine in rawhide.
>
> Chromium has a lot of bundled components, so it is usually fairly resistant
> to system changes. There are no differences between how Chromium builds
> (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> %{optflags}, so the compiler flags are equivalent.
>
> Could this be due to some quirk of binutils in the way chromium gets linked
> in rawhide? Is there something else unique to how packages are built in
> rawhide right now? Are any other rawhide packages having similar string
> issues?

Have you tried the reverse?  rawhide-built chromium into fc33?

Thanks,
--Robbie