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(a)redhat.com> wrote:
Tom Callaway <spotrh(a)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