Support native builds with LLVM runtime

[rakuco]

At the moment, RUNTIME = "llvm" only causes target builds to use libc++, compiler_rt etc.

See OSSystems/meta-browser#488 for a case where it'd be useful to have it working for native builds too: part of the Chromium build involves building some tools that are run on the host during the build itself; right now they are still built with libstdc++ even though RUNTIME = "llvm" is being set.

[kraj]

Clearly RUNTIME is only meant to affect target and that's what you are seeing. if we should build libc++/compiler-rt for build host is an enhancement that would certainly make sense to offer clang SDK on many linux hosts.

[rakuco]

Just for the record, OSSystems/meta-browser#517 contains more information about hiccups people have hit due to libstdc++ being used in native builds. According to https://github.com/OSSystems/meta-browser/issues/517#issuecomment-869804396 libcxx-native is building fine now, but clang-native is unable to use it.

[kraj]

yes, its a harder issue than normal, since clang's way to use stdandard C++ library is governed via sysroot option if we need to change it to non-default locations and this needs to change for this to work in OE since we want a mix of search paths that is not standard.

[kraj]

@rakuco I have it working now see https://github.com/YoeDistro/meta-browser/commits/yoe/mut

[rakuco]

Nice to hear! Can you clarify what changes are needed where? https://github.com/YoeDistro/meta-browser/commit/d0436f6a4059e7d9f878ccdf4b9f031cee77b373 looks like an obvious candidate, but its commit message also mentions some changes in meta-clang.

[kraj]

all patches in yoe/mut are needed. Except that we maybe fix-sql-virtualcursor-error.patch is no longer needed. I have not yet tested that but let me try to disable that.

[kraj]

OK I varified that we dont need fix-sql-virtualcursor-error.patch after my changes anymore, so I have staged a removal of it in yoe/mut

[rakuco]

Good.

Is there a way to move those changes you've made to the chromium recipe back to meta-clang? That is, if one does something like RUNTIME = "llvm" or RUNTIME_class-native = "llvm" makes it use libcxx-native, compiler-rt-native and adjusts CPPFLAGS and LDFLAGS.

[rakuco]

Also, does it mean the changes you've landed to YoeDistro cannot land into the main meta-browser repo because it'd break compatibility with the other, non-master branches?

[rakuco]

@r1mikey @TonyTascioglu fyi

[TonyTascioglu]

Just want mention that building with https://github.com/YoeDistro/meta-browser/tree/d0436f6a4059e7d9f878ccdf4b9f031cee77b373 for meta-browser and meta-clang master worked to build chromium-x11 on poky/master. Interesting that some of the patches were still needed despite the llvm change.

[rakuco]

Interesting that some of the patches were still needed despite the llvm change.

My uninformed guess is that the headers from the patches that are still necessary ended up being included implicitly by whatever libc++ version was in use at the time, but the version we have in meta-clang master is newer and ends up requiring those missing headers to be included explicitly (which would end up happening sooner or later).

[kraj]

Just want mention that building with https://github.com/YoeDistro/meta-browser/tree/d0436f6a4059e7d9f878ccdf4b9f031cee77b373 for meta-browser and meta-clang master worked to build chromium-x11 on poky/master. Interesting that some of the patches were still needed despite the llvm change.

can you try tip of yoe/mut branch in your env please ? I have removed the libstdc++ patch that was added by your patch earlier.

[TonyTascioglu]

I have not tried the mut branch yet, I can give it a go. Would these changes be merged from YoeDistro/meta-browser to OSSystems/meta-browser?

[TonyTascioglu]

I switched to the mut branch and did a build overnight, it looks it failed.

BUILDALL-QEMU LOG FOR chromium-x11
START TIME: 2021-07-12_13:57:35
HOSTNAME: ala-lpggp3
HOST OS: Ubuntu 18.04.3 LTS
HOST KERNEL: 5.4.0-74-generic
===============
BUILD RESULTS:
[glibc]
FAIL: qemuriscv32
FAIL: qemuarmv5
FAIL: qemumips
FAIL: qemux86-64
FAIL: qemuarm64
FAIL: qemumips64
FAIL: qemuarm
FAIL: qemuppc
FAIL: qemuriscv64
FAIL: qemuppc64
FAIL: qemux86
[musl]
FAIL: qemuriscv32
FAIL: qemuarmv5
FAIL: qemumips
FAIL: qemux86-64
FAIL: qemuarm64
FAIL: qemumips64
FAIL: qemuarm
FAIL: qemuppc
FAIL: qemuriscv64
FAIL: qemuppc64
FAIL: qemux86
===============
PASSED: 0
FAILED: 22

Looks like this might be the error:

 | 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.

Which I suppose makes sense since the difference between the mut branch and d0436f6a4 is the removal of that patch.

Branches used:

meta                 
meta-poky            
meta-yocto-bsp       = "master:5e6b4111982a1c0ede238390a450881cde4b03e5"
meta-chromium        = "yoe/mut:57b93c0dde12866ce8df7516bc7aba0ea3505305"
meta-clang           = "master:77394fabd1fee7f4ea3a9358dfba7e94e6a98e8d"
meta-rust            = "master:1b59fd45906082c978d0a0a6e4e51a0ea4aa32c7"
meta-oe              = "master:0412a4befcd190cf020dd525aad31eba54b93a32"
meta-python2         = "master:8db9e4f6ceae33d7a4f55453d31e69f9858af4eb"
meta-raspberrypi     = "master:0e48785e15d864438cade6e526056dbc92e7a690"

Something to note: even with the d0436f6a4 branch, all the musl builds fail, so we might need a change to those patches.

[r1mikey]

Apologies for the delay on my side - it's an admin-heavy time of the year.

Building for an x86-64-based platform, all went smoothly and looks correct. I added the necessary changes to my .bbappend and disabled parts of meta-intel that blindly apply incorrect SPIRV patches to trunk LLVM.

After building, I checked one of the native build utilities, and it seems to be correctly linked.

As somebody else noted, the supp_size patch is needed. I didn't apply any other patches (that I didn't already have) to the Chromium source tree.

[out/Release] ldd yocto_native/flatc
	linux-vdso.so.1 (0x00007fff3915f000)
	libc++abi.so.1 => /REDACTED/chromium-ozone-wayland/91.0.4472.114-r0/recipe-sysroot-native/usr/lib/libc++abi.so.1 (0x00007f192698e000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f192676e000)
	libc++.so.1 => /REDACTED/chromium-ozone-wayland/91.0.4472.114-r0/recipe-sysroot-native/usr/lib/libc++.so.1 (0x00007f192649f000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f192611d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1925d58000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1925b40000)
	REDACTED/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1926bd1000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f1925938000)
	libatomic.so.1 => /lib64/libatomic.so.1 (0x00007f1925730000)
[out/Release] ```

[r1mikey]

Cursory device-side checking looks good as well.