Chromium build errors

[TonyTascioglu]

Hello, Checking out from master and building Chromium currently results in errors.

The compile process fails due to the following error:

| ../../third_party/harfbuzz-ng/src/src/hb-subset-cff1.cc:405:33: error: variable 'supp_size' set but not used [-Werror,-Wunused-but-set-variable]
|     unsigned int  size0, size1, supp_size;
|                                 ^
| 1 error generated.

This is due to the harfbuzz third-party library, and was fixed in harfbuzz with commit 243d056ff1c2af583ceb67e5dfbfaac51dc96e63

I created a patch to cherry pick the commit to fix this issue, and updated the chromium-gn.inc file to apply the patch. This fixed that original error but let to a different one:

| ../../third_party/ruy/src/ruy/block_map.cc:375:25: error: no member named 'numeric_limits' in namespace 'std'
|   int best_score = std::numeric_limits<int>::min();
|                    ~~~~~^
| ../../third_party/ruy/src/ruy/block_map.cc:375:43: error: expected '(' for function-style cast or type construction
|   int best_score = std::numeric_limits<int>::min();
|                                        ~~~^
| ../../third_party/ruy/src/ruy/block_map.cc:375:46: error: no member named 'min' in the global namespace
|   int best_score = std::numeric_limits<int>::min();
|                                            ~~^
| 3 errors generated.

Similarly, this is due to google's ruy library. There is commit upstream that fixes this: 3c93cda8211efa01128d48950f0d6ee5233c5b9b, so I created a similar patch for it and applied it.

This fixed this issue but led a final one:

| In file included from ../../sql/recover_module/cursor.cc:5:
| ../../sql/recover_module/cursor.h:65:5: error: static_assert failed due to requirement 'std::is_standard_layout<sql::recover::VirtualCursor>::value' "needed for the reinterpret_cast below"
|     static_assert(std::is_standard_layout<VirtualCursor>::value,
|     ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 1 error generated.

Unlike the others, this is not fixed upstream yet. We're led to believe this may be due to stricter compiler rules in master for oe now.

I have attached the 2 patches to fix the earlier issues as reference.

Thanks!

fix-harfbuzz-supp-size.patch.txt fix-ruy-numeric-limits.patch.txt

[kraj]

master is moving towards clang-13 and that does have newer warnings what you are seeing. These patches are valid and perhaps you should check in chromium master and see if they are already fixed. for std::is_standard_layout issue try this patch

https://github.com/ungoogled-software/ungoogled-chromium-archlinux/blob/master/sql-VirtualCursor-standard-layout.patch

[kraj]

thinking more about this error, it seems to be linking with libbstc++ and not with libc++, so why is that happening for you ? Recently we made the change to switch standard C++ runtime to use clang libc++ but it seems thats not effective in your builds.

[r1mikey]

thinking more about this error, it seems to be linking with libbstc++ and not with libc++, so why is that happening for you ? Recently we made the change to switch standard C++ runtime to use clang libc++ but it seems thats not effective in your builds.

I'm seeing similar errors too, both with master and hardknott meta-clang. From what I can see, clang will first search the /opt/rh/devtoolset-[2-10] on Redhat/CentOS machines (done here D59987), then it looks in /usr. When provided with a --gcc-toolchain, it needs a fairly explicit match on the target triple (host triple), so it ends up treating one of the devtoolset or system installations as the "best" GCC toolchains to use. In my case, this is devtoolset-8.

Clang is definitely falling back to GCC in my case, not picking up the LLVM runtimes. I've been scratching my head a little over this for the last few days, but I'm no closer to resolution. My failing host system is CentOS 7 - my CentOS 8 host works as expected with both Hardknott and master.

I also saw the first error, but I just patched that out in a bbappend - this simply seems to be a new/stricter warning in the newer compiler.

[r1mikey]

I've been digging into this a bit today. Here's what I've found.

libc++ (and friends) does not get installed to the chromium recipe-sysroot, and I think this is what triggers the fallback behaviour to find a usable GCC installation. I ran into problems building libcxx-native, and I need to iterate a few more times to ensure that I have the right set of flags in all recipes, but here's what I've got so far:

In a bbappend to Chromium, I add: DEPENDS_append = " libcxx-native"

I might need the following, but I'm testing without it at the moment: BUILD_CXXFLAGS_append = " -stdlib=libc++"

libcxx-native tries to build with g++, which fails dismally. I've set the BUILD_ variables to get this building with clang, but ran into issues with AR and RANLIB (it looks like this is weirdness in the find_library parts of the cmake toolchains). To get around this I've defined -DCMAKE_AR and -DCMAKE_RANLIB to point directly to the right binaries.

[r1mikey]

Yeah, definitely some issues on the native side that I won't be able to easily resolve.

I'm struggling to have clang pick up the libc++-abi library, and when I add -rtlib=compiler-rt for the runtime I get:

python "../../build/toolchain/gcc_link_wrapper.py" --output="yocto_native/flatc" -- clang++ -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -L/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/usr/lib                         -L/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/lib                         -Wl,--enable-new-dtags                         -Wl,-rpath-link,/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath-link,/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/lib                         -Wl,-rpath,/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath,/data/users/rmikey/gizmo-build/tmp/work/corei7-64-gizmos-linux/chromium-ozone-wayland/91.0.4472.77-r0/recipe-sysroot-native/lib                         -Wl,-O1 -Wl,--allow-shlib-undefined -Wl,--dynamic-linker=/data/users/rmikey/gizmo-build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 -stdlib=libc++ -rtlib=compiler-rt -o "yocto_native/flatc" -Wl,--start-group @"yocto_native/flatc.rsp"  -Wl,--end-group  -ldl -lpthread -lrt
ld.lld: error: cannot open /usr/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory
ld.lld: error: cannot open /usr/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory

So I think there's a bit more work to do before host-side clang is usable for Chromium.

[msisov]

What yocto branch are you using? Is it hardknott? I haven't tested build with that yet. But given Gatesgarth is EOL with dunfell going to LTS and Hardknott as the latest branch, I need to modify our bot to finally work with hardknott. I am pretty busy with Ozone/Wayland development, and given that vacation time is coming, my timetable is tight :\

[TonyTascioglu]

What yocto branch are you using? Is it hardknott? I haven't tested build with that yet. But given Gatesgarth is EOL with dunfell going to LTS and Hardknott as the latest branch, I need to modify our bot to finally work with hardknott. I am pretty busy with Ozone/Wayland development, and given that vacation time is coming, my timetable is tight :\

I am testing on master for poky and the other required layers.

[TonyTascioglu]

Update: applying https://github.com/ungoogled-software/ungoogled-chromium-archlinux/blob/master/sql-VirtualCursor-standard-layout.patch on top of the original 2 patches I posted allows it to build successfully. This doesn't address the c++ and clang errors, but it is a workaround to have it build until it's addressed.

[kraj]

Can you submit s pull request with these three patches please? building with libcstdc++ is still an option even though it it not preferred. We are only using it for host pieces as of now.

[r1mikey]

On digging a little, older GCC is no longer going to be possible after the introduction of MetadataAllocator, which is implemented in C++20-style, which doesn't include a rebind template in the allocator.

https://sourcegraph.com/github.com/chromium/chromium@5e8d822cc4a0f85cc9b3cfc7a9032840ba83c578/-/blob/base/allocator/partition_allocator/starscan/metadata_allocator.h?L70=&utm_source=share#tab=history

I'll continue hacking down this path in the short term, but for longer-term build stability we're definitely going to want a freshly built host clang to isolate form these sort of changes.

[TonyTascioglu]

PR open. https://github.com/OSSystems/meta-browser/pull/520 It's not ideal to be patching third party libraries in Chromium, but until we fix the root cause, this allows chromium-x11 and chromium-ozone-wayland to build.

[rakuco]

Thanks everyone for the deep investigation. When we switched to libc++ in the Chromium build, we intentionally continued to build the native bits with libstdc++ due to a lack of support for native builds with the LLVM runtime back then. See #488 as well as kraj/meta-clang#449.

Speaking of the latter: @kraj, I see that kraj/meta-clang#468 mentions the issue above, can you clarify what the current status in meta-clang is when it comes to doing native builds with libc++ rather than the host's libstdc++?

Now as for the issues being seen here: @r1mikey @TonyTascioglu I'm a bit confused as to when the build issues are happening. Is it with OE master and hardknott? Only on old CentOS releases or not? Is the system's GCC really being used or are we talking about libstdc++ and the rest of the GNU toolchain (it'd be really odd if the actual compiler was GCC given the work we've done so far)?

[r1mikey]

I've been pursuing two lines of investigation:

1. Upgrading meta-clang to master (and appending out interference from meta-intel SPIRV patches)
2. Patching Chromium to continue to work with libstdc++ (devtoolset-8 on CentOS 7, for my sins)

The first approach is most desirable, but unfortunately the native clang still has a few issues. Particularly:

1. Runtimes are not pulled into the recipe native sysroot, solved by depending on them
2. libc++ builds using the system g++, solved by an append
3. When linking, the compiler runtime is linked using an absolute path on the host system, which fails

I gave up after (3) above, but that could probably be resolved by passing -isysroot to the native compiler. All of these challenges are best solved in meta-clang, not in this repo.

My second approach ended up centering on MetadataAllocator (in base/allocator/partition_allocator/starscan/pcscan.cc). The Allocator requirements have evolved through C++17 and C++20, with C++17 deprecating a lot of allocator boilerplate in favour of allocator_traits, and C++20 removing the same. I've just (a few minutes ago) completed a build on CentOS 7 with devtoolset-8 with a modified MetadataAllocator. I'm happy to put up a PR with this patch shortly, once I get a little more testing done.

[r1mikey]

I should also mention that when I updated meta-clang I saw the Harfbuzz supp_size issue as well.

[TonyTascioglu]

As a note, from my builds, it looks like chromium is indeed linking with libstdc++

(build/tmp/work/cortexa57-poky-linux/chromium-x11/91.0.4472.114-r0/packages-split)
[tony@desktop packages-split]$ ldd chromium-x11/usr/lib/chromium/chromium-bin | grep c++
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa98be58000)

However, from my understanding, this is unlikely to be related to the host or linking to the system libraries, since the ARM build is also linked to libstdc++

(build/tmp/work/core2-64-poky-linux/chromium-x11/91.0.4472.114-r0/packages-split)
[tony@desktop packages-split]$ readelf -a chromium-x11/usr/lib/chromium/chromium-bin | grep c++
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
  0x00b0: Version: 1  File: libstdc++.so.6  Cnt: 17 

I have only tested builds using the master branch of the following layers: meta-openembedded/meta-oe, meta-rust, meta-clang, meta-python2, meta-browser/meta-chromium. I can run a test overnight with the respective hardknott branches as well.

[TonyTascioglu]

For reference, this was my build configuration where after I encountered and patched the issue.

buildtest is my local meta-browser branch that included both the patches from #520 and the uprev from #521. The other repos were not changed between the broken and patched build.

Build Configuration:
BB_VERSION           = "1.51.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.3+snapshot-dfed30ed734891915c08c9ddf1691641720686e9"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "master:dfed30ed734891915c08c9ddf1691641720686e9"
meta-oe              = "master:3d8715dff55e06ea99043881b06b30fbaaf03a36"
meta-rust            = "master:ab86e0a068e90c361b803f59a4baa79bf0c92ba7"
meta-clang           = "master:7980d949ceaa72e76ed02a335ec1f94459ee5e31"
meta-python2         = "master:810d6d842f103eb59f18b06426106462b15de7e2"
meta-chromium        = "buildtest:e5a74c78d49e34a10c9026bb003173052ec28d65"

[rakuco]

Speaking of the latter: @kraj, I see that kraj/meta-clang#468 mentions the issue above, can you clarify what the current status in meta-clang is when it comes to doing native builds with libc++ rather than the host's libstdc++?

@kraj friendly ping. I'd like to understand the situation in meta-clang better. It sounds like there's some work left to do there that would address some of the issues being reported here.

[kraj]

@rakuco I have fixed building libcxx-native with latest meta-clang/trunk, this is now building fine, however clang-native is not able to find it when using -stdlib=libc++ because its hardcoded to look under sysroot which in native case points to / which means it looks for this library in /usr/lib. This needs to be fixed because our native clang use in OE is a a bit different than normal, because we want it to use things from our native-sysroot and then fallback to build systems libs/headers for rest, however clang does not have this working out of box, so I have to make clang work in this way which would need patching clang. I plan to look into making libcxx-native usable in coming weeks.

For now, lets accept this patchset until we get clang-native/libcxx-native work in tandem.

[rakuco]

However, from my understanding, this is unlikely to be related to the host or linking to the system libraries, since the ARM build is also linked to libstdc++

(build/tmp/work/core2-64-poky-linux/chromium-x11/91.0.4472.114-r0/packages-split)
[tony@desktop packages-split]$ readelf -a chromium-x11/usr/lib/chromium/chromium-bin | grep c++
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
  0x00b0: Version: 1  File: libstdc++.so.6  Cnt: 17 

I have only tested builds using the master branch of the following layers: meta-openembedded/meta-oe, meta-rust, meta-clang, meta-python2, meta-browser/meta-chromium. I can run a test overnight with the respective hardknott branches as well.

Did you get the change to try the hardknott branch as well? I've built chromium-x11 with MACHINE="intel-corei7-64" on hardknott with the latest meta-browser master, and got this with devshell:

root@rkubodac-desk]/path/to/build-hardknott-intel-corei7-64/tmp/work/corei7-64-poky-linux/chromium-x11/91.0.4472.114-r0/chromium-91.0.4472.114# readelf -d out/Release/chrome | fgrep c++
 0x0000000000000001 (NEEDED)             Shared library: [libc++.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc++abi.so.1]

[TonyTascioglu]

I did a build using https://github.com/YoeDistro/meta-browser/tree/d0436f6a4059e7d9f878ccdf4b9f031cee77b373 for meta-browser and using the latest meta-clang.I can confirm that it allowed chromium-x11 to build on Poky/master without errors. The qemu version worked to launch chromium from my test.

(the build for the raspberry pi still has the website connection problem with the network service, but that's unrelated to this and belongs in https://github.com/OSSystems/meta-browser/issues/511)