Open MaxIhlenfeldt opened 1 year ago
rakuco
commented
1 year ago Just to confirm: is this something that only happens on dunfell? At first it sounds like an issue that'd be reproducible on all branches. If not, I guess the good news is that this has already been fixed in other branches :-)
MaxIhlenfeldt
commented
1 year ago I've only ever seen it on dunfell, yes. But I only ever build chromium-x11 on dunfell, and chromium-ozone-wayland on other releases, do you think that might make a difference?
rakuco
commented
1 year ago I think not, I'd expect chromium-ozone-wayland to also have to build the native BoringSSL bits just like the X11 version.
At this point I don't remember if we also build libc++ on the host. Looking at the logs above we at least build clang-native, but it seems to be using the host's libstdc++.
MaxIhlenfeldt
commented
1 year ago I've tried to get the dunfell build working on another machine (Arch Linux), but that one already fails to compile nodejs-native (same as on my other Arch machine):
| gcc -o Release/obj.host/v8_zlib/deps/v8/third_party/zlib/gzlib.o ../deps/v8/third_party/zlib/gzlib.c '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64' '-D__STDC_FORMAT_MACROS' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' '-DV8_TARGET_ARCH_X64' '-DV8_EMBEDDER_STRING="-node.84"' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT=1' '-DENABLE_MINOR_MC' '-DOBJECT_PRINT' '-DV8_INTL_SUPPORT' '-DV8_CONCURRENT_MARKING' '-DV8_ARRAY_BUFFER_EXTENSION' '-DV8_ENABLE_LAZY_SOURCE_POSITIONS' '-DV8_USE_SIPHASH' '-DDISABLE_UNTRUSTED_CODE_MITIGATIONS' '-DV8_WIN64_UNWINDING_INFO' '-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH' '-DV8_SNAPSHOT_COMPRESSION' '-DZLIB_IMPLEMENTATION' -I/home/max/yocto-chromium/builds/ci-chromium-x11-rpi4-dunfell/tmp-glibc/work/x86_64-linux/nodejs-native/14.18.1-r0/recipe-sysroot-native/usr/include -I../deps/v8 -I../deps/v8/include -I../deps/v8/third_party/zlib -I../deps/v8/third_party/zlib/google -pthread -Wno-unused-parameter -m64 -Wno-return-type -fno-strict-aliasing -m64 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -MMD -MF .//Release/.deps/Release/obj.host/v8_zlib/deps/v8/third_party/zlib/gzlib.o.d.raw -isystem/home/max/yocto-chromium/builds/ci-chromium-x11-rpi4-dunfell/tmp-glibc/work/x86_64-linux/nodejs-native/14.18.1-r0/recipe-sysroot-native/usr/include -isystem/home/max/yocto-chromium/builds/ci-chromium-x11-rpi4-dunfell/tmp-glibc/work/x86_64-linux/nodejs-native/14.18.1-r0/recipe-sysroot-native/usr/include -O2 -pipe -c
| In file included from ../deps/v8/src/base/macros.h:12,
| from ../deps/v8/src/libplatform/worker-thread.h:12,
| from ../deps/v8/src/libplatform/worker-thread.cc:5:
| ../deps/v8/src/base/logging.h: In function ‘typename std::enable_if<(std::is_enum<_Tp>::value && (! v8::base::has_output_operator<T>::value)), std::__cxx11::basic_string<char> >::type v8::base::PrintCheckOperand(T)’:
| ../deps/v8/src/base/logging.h:170:34: error: ‘uint8_t’ was not declared in this scope
| 170 | std::is_same<underlying_t, uint8_t>::value, uint16_t,
| | ^~~~~~~
| ../deps/v8/src/base/logging.h:16:1: note: ‘uint8_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
| 15 | #include "src/base/template-utils.h"
| +++ |+#include <cstdint>
| 16 |
| ../deps/v8/src/base/logging.h:170:41: error: template argument 2 is invalid
| 170 | std::is_same<underlying_t, uint8_t>::value, uint16_t,
| | ^
| ../deps/v8/src/base/logging.h:170:51: error: ‘uint16_t’ was not declared in this scope
| 170 | std::is_same<underlying_t, uint8_t>::value, uint16_t,
| | ^~~~~~~~
| ../deps/v8/src/base/logging.h:170:51: note: ‘uint16_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
| ../deps/v8/src/base/logging.h:172:61: error: template argument 1 is invalid
| 172 | int16_t, underlying_t>::type>::type;
| | ^
| ../deps/v8/src/base/logging.h:172:61: error: template argument 2 is invalid
| ../deps/v8/src/base/logging.h:172:62: error: ‘<declaration error>’ is not a template [-fpermissive]
| 172 | int16_t, underlying_t>::type>::type;
| | ^~
| ../deps/v8/src/base/logging.h:173:40: error: ‘int_t’ does not name a type; did you mean ‘wint_t’?
| 173 | return PrintCheckOperand(static_cast<int_t>(static_cast<underlying_t>(val)));
| | ^~~~~
| | wint_t
| ../deps/v8/src/base/macros.h: At global scope:
| ../deps/v8/src/base/macros.h:338:25: error: ‘intptr_t’ has not been declared
| 338 | inline T RoundDown(T x, intptr_t m) {
| | ^~~~~~~~
| ../deps/v8/src/base/macros.h:344:11: error: ‘intptr_t’ has not been declared
| 344 | template <intptr_t m, typename T>
| | ^~~~~~~~
| ../deps/v8/src/base/macros.h: In function ‘constexpr T RoundDown(T)’:
| ../deps/v8/src/base/macros.h:348:17: error: ‘m’ was not declared in this scope
| 348 | STATIC_ASSERT(m != 0 && ((m & (m - 1)) == 0));
| | ^
| ../deps/v8/src/base/macros.h:200:43: note: in definition of macro ‘STATIC_ASSERT’
| 200 | #define STATIC_ASSERT(test) static_assert(test, #test)
| | ^~~~
| ../deps/v8/src/base/macros.h: At global scope:
| ../deps/v8/src/base/macros.h:354:23: error: ‘intptr_t’ has not been declared
| 354 | inline T RoundUp(T x, intptr_t m) {
| | ^~~~~~~~
| ../deps/v8/src/base/macros.h:358:11: error: ‘intptr_t’ has not been declared
| 358 | template <intptr_t m, typename T>
| | ^~~~~~~~
| ../deps/v8/src/base/macros.h: In function ‘constexpr T RoundUp(T)’:
| ../deps/v8/src/base/macros.h:361:20: error: ‘m’ was not declared in this scope
| 361 | return RoundDown<m, T>(static_cast<T>(x + (m - 1)));
| | ^
| ../deps/v8/src/base/macros.h: In function ‘void* AlignedAddress(void*, size_t)’:
| ../deps/v8/src/base/macros.h:372:51: error: ‘uintptr_t’ does not name a type
| 372 | return reinterpret_cast<void*>(reinterpret_cast<uintptr_t>(address) &
| | ^~~~~~~~~
| ../deps/v8/src/base/macros.h:13:1: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
| 12 | #include "src/base/logging.h"
| +++ |+#include <cstdint>
| 13 |
| ../deps/v8/src/base/macros.h:373:47: error: ‘uintptr_t’ does not name a type
| 373 | ~static_cast<uintptr_t>(alignment - 1));
| | ^~~~~~~~~
| ../deps/v8/src/base/macros.h:373:47: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; did you forget to ‘#include <cstdint>’?
| make[1]: *** [tools/v8_gypfiles/v8_libplatform.host.mk:141: Release/obj.host/v8_libplatform/deps/v8/src/libplatform/worker-thread.o] Error 1I think this is because of the same underlying error - this V8 CL suggests to me that the GCC headers are used, which internally changed some of there imports in GCC 13, leading to these errors.
MaxIhlenfeldt
commented
1 year ago @kraj as this seems to be a dunfell-specific problem, not sure if looking at https://github.com/kraj/meta-clang/compare/dunfell-clang12...kirkstone makes sense to maybe find out what fix kirkstone has that dunfell hasn't (probably in classes/clang.bbclass)?
rakuco
commented
1 year ago The nodejs-native issue seems to be different, as these other recipes are expected to use GCC by default anyway. You're not getting this error in kirkstone because Khem fixed the recipe there: https://github.com/openembedded/meta-openembedded/commit/4cc7363978f81736e09ec675748401346a00391a
I think this specific issue can go away if the same fix is backported to 14.x.
kraj
commented
1 year ago See https://github.com/openembedded/meta-openembedded/commit/116bfe8d5e5851e7fc5424f40da8691a19c5b5ee
it was done exactly for supporting latest chromium so please do the preferred version thing when building chromium
MaxIhlenfeldt
commented
1 year ago I have PREFERRED_VERSION_nodejs-native = "14.%" in my conf/local.conf, is that not enough? It seems that the patch @rakuco linked above is missing for dunfell.
kraj
commented
1 year ago That enough for supported build hosts for dunfell. If you are using some other distro which is using gcc13 then it might be an issue and if someone can validate that this would work then proposing a backport to dunfell for meta-oe might be ok
MaxIhlenfeldt
commented
1 year ago Yes, Arch Linux has updated to gcc13 already (Fedora 38 as well, and more distros will follow). I've confirmed that manually applying the changes from the linked patch fixes this build error. However, there's another build error that needs to be fixed: https://bugs.gentoo.org/904878
The upstream v8 fix that Gentoo backported requires a slight tweak: it uses std::{con,dis}junction, which are only available since C++17, but we're compiling NodeJS with -std=gnu++1y (i.e. C++14); luckily, the version of v8 used still has its own sec/base/type-traits.h that provides conjunction and disjunction. Thus, if we modify the patch to include that header and use {con,dis}junction instead of std::{con,dis}junction, everything works.
I can provide the patch files, maybe you could then please propose adding them to meta-oe?
Iniesta8
commented
1 year ago That enough for supported build hosts for dunfell. If you are using some other distro which is using gcc13 then it might be an issue and if someone can validate that this would work then proposing a backport to dunfell for meta-oe might be ok
I get the errors even though I meet all the requirements for dunfell:
I've also picked the commit hash e8a756bb5ee28ee5adc668b78ff2011b0f3b62bd of meta-browser that provides chromium-x11-112.0.5615.165...but I don't get it compiled.
Is there anything else I'm missing?
MaxIhlenfeldt
commented
1 year ago As this is fixed with the experimental dunfell-clang14 branch (mind that it's currently in a different repo, see https://github.com/kraj/meta-clang/issues/835), I don't think you're missing something and this is just a bug with meta-clang/dunfell-clang12.
Example error (happens for multiple files):
(first seen here)
I checked using
bitbake -c devshell chromium-x11and indeed, the native version uses host headers, while the cross-compile version does not: