OSSystems / meta-browser

OpenEmbedded/Yocto BSP layer for Web Browsers
MIT License
184 stars 191 forks source link

[Regression] Bitbake unbuildable dependency error after 967f28f0404cef3b74fb9d0d3c897b65b15adcdf on hardknott #535

Open psaavedra opened 3 years ago

psaavedra commented 3 years ago

This error was introduced by https://github.com/OSSystems/meta-browser/commit/967f28f0404cef3b74fb9d0d3c897b65b15adcdf in combination with TCLIBC=glibc (default setting) and RUNTIME ="llvm" (established by meta-browser/meta-chromium/recipes-browser/chromium/chromium.inc:25):

MACHINE=qemuarm DISTRO=poky TCLIBC=glibc bitbake chromium-ozone-wayland
$ MACHINE=qemuarm DISTRO=poky TCLIBC=glibc bitbake chromium-ozone-wayland
ERROR: Nothing PROVIDES 'virtual/libc-native' (but virtual:native:/home/bot/yocto-browsers/sources/meta-clang/recipes-devtools/clang/compiler-rt_git.bb DEPENDS on or otherwise requires it). Close matches:
  virtual/libgl-native
  virtual/librpc-native
  virtual/libx11-native
ERROR: Required build target 'chromium-ozone-wayland' has no buildable providers.
Missing or unbuildable dependency chain was: ['chromium-ozone-wayland', 'gn-native', 'compiler-rt-native', 'virtual/libc-native']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

and

$ MACHINE=qemuarm DISTRO=poky TCLIBC=glibc bitbake chromium-ozone-wayland
ERROR: Nothing PROVIDES 'virtual/compilerlibs-native' (but virtual:native:/home/bot/yocto-browsers/sources/meta-clang/recipes-devtools/clang/compiler-rt_git.bb DEPENDS on or otherwise requires it). Close matches:
  virtual/libsdl-native
  virtual/libusb0-native
  virtual/mesa-native
ERROR: Required build target 'chromium-ozone-wayland' has no buildable providers.
Missing or unbuildable dependency chain was: ['chromium-ozone-wayland', 'gn-native', 'compiler-rt-native', 'virtual/compilerlibs-native']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

Environment:

Build Configuration:
BB_VERSION           = "1.50.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "qemuarm"
DISTRO               = "poky"
DISTRO_VERSION       = "3.3.2"
TUNE_FEATURES        = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            = "HEAD:3f9e8dfde19f62bfda2308437f18fca58d7363e9"
meta-oe              
meta-multimedia      
meta-perl            
meta-python          
meta-networking      
meta-filesystems     
meta-python2         = "HEAD:8db9e4f6ceae33d7a4f55453d31e69f9858af4eb"
meta-clang           = "HEAD:7ef47d048267cf755c496a3962b34314f6f1f1e1"  <<<<<<<<<<<   hardknott branch HEAD
meta-chromium        = "HEAD:967f28f0404cef3b74fb9d0d3c897b65b15adcdf"
meta-rust            = "HEAD:448047c7e4746eac8f0a96a2e3966b2219e2a4ca"
psaavedra commented 3 years ago

Apparently this dependency block is addressed later in meta-clang (master, but not for the hardknott branch):

https://github.com/kraj/meta-clang/blame/eb92914e31ff872c032155997c42ca8b6e6d82a3/recipes-devtools/clang/compiler-rt_git.bb#L24

added on meta-clang in the commit: https://github.com/kraj/meta-clang/commit/17737cc4ecd3aea2c978bf83e283bcb08d097487

Something like the following could be needed in meta-clang (hardknott branch):

diff --git a/recipes-devtools/clang/compiler-rt_git.bb b/recipes-devtools/clang/compiler-rt_git.bb
index 0579395..681eaed 100644
--- a/recipes-devtools/clang/compiler-rt_git.bb
+++ b/recipes-devtools/clang/compiler-rt_git.bb
@@ -19,8 +19,10 @@ TUNE_CCARGS_remove = "-no-integrated-as"

 INHIBIT_DEFAULT_DEPS = "1"

-DEPENDS += "ninja-native clang-cross-${TARGET_ARCH} virtual/${MLPREFIX}libc virtual/${TARGET_PREFIX}compilerlibs"
-DEPENDS_append_class-nativesdk = " clang-native"
+DEPENDS += "ninja-native"
+DEPENDS:append:class-target = " clang-cross-${TARGET_ARCH} virtual/${MLPREFIX}libc virtual/${TARGET_PREFIX}compilerlibs"
+DEPENDS:append:class-nativesdk = " clang-native"
+DEPENDS:append:class-native = " clang-native"

 PACKAGECONFIG ??= ""
 PACKAGECONFIG[crt] = "-DCOMPILER_RT_BUILD_CRT:BOOL=ON,-DCOMPILER_RT_BUILD_CRT:BOOL=OFF"
otavio commented 3 years ago

@kraj can you take a look at this?

kraj commented 3 years ago

native versions of compiler-rt and libcxx is needed and we did not have them in hardknott. If you can test these on hadknott/meta-clang that would be appreciated and we can backport them. I am more worried about dunfell. I think we will have to do significant work to keep going on dunfell.

otavio commented 3 years ago

Dunfell is important as many people rely on it due it being an LTS release. Either way, one issue at time. @psaavedra can you check what @kraj proposed?

psaavedra commented 3 years ago

native versions of compiler-rt and libcxx is needed and we did not have them in hardknott.

Can you be more specific. Why are they needed? Apparently chromium builds ok with the glibc. is something specific of building for musl ?

If you can test these on hadknott/meta-clang that would be appreciated and we can backport them. I am more worried about dunfell. I think we will have to do significant work to keep going on dunfell.

Unfortunately, my proposal still doesn't work.

I have this error building compiler-rt-native/12.0.0-r0

/bin/sh: 1: /tmp/work/x86_64-linux/compiler-rt-native/12.0.0-r0/recipe-sysroot-native/usr/bin/x86_64-linux/llvm-ar: not found

but exist: tmp/work/x86_64-linux/compiler-rt-native/12.0.0-r0/recipe-sysroot-native/usr/bin/llvm-ar. Any suggestion?

psaavedra commented 3 years ago

The alternative that I've found to keep the build working for the glibc is this:

diff --git a/meta-chromium/recipes-browser/chromium/gn-native_92.0.4515.107.bb b/meta-chromium/recipes-browser/chromium/gn-native_92.0.4515.107.bb
index 2f135bf..cfd1d30 100644
--- a/meta-chromium/recipes-browser/chromium/gn-native_92.0.4515.107.bb
+++ b/meta-chromium/recipes-browser/chromium/gn-native_92.0.4515.107.bb
@@ -28,11 +28,11 @@ BUILD_LD = "${CXX}"
 BUILD_AR = "llvm-ar"

 DEPENDS = "clang-native ninja-native"
-DEPENDS:append:runtime-llvm = " compiler-rt-native libcxx-native"
+DEPENDS:append:runtime-llvm = "${@bb.utils.contains('TCLIBC', 'musl', ' compiler-rt-native libcxx-native', '' ,d)}"
 # Use libcxx headers for native parts
-CXXFLAGS:append:runtime-llvm = " -isysroot=${STAGING_DIR_NATIVE} -stdlib=libc++"
+CXXFLAGS:append:runtime-llvm = "${@bb.utils.contains('TCLIBC', 'musl', ' -isysroot=${STAGING_DIR_NATIVE} -stdlib=libc++', '' ,d)}"
 # Use libgcc for native parts
-LDFLAGS:append:runtime-llvm = " -rtlib=libgcc -unwindlib=libgcc -stdlib=libc++ -lc++abi -rpath ${STAGING_LIBDIR_NATIVE}"
+LDFLAGS:append:runtime-llvm = "${@bb.utils.contains('TCLIBC', 'musl', ' -rtlib=libgcc -unwindlib=libgcc -stdlib=libc++ -lc++abi -rpath ${STAGING_LIBDIR_NATIVE}', '' ,d)}"

 do_configure[noexec] = "1"

See MR: https://github.com/OSSystems/meta-browser/pull/537

r1mikey commented 3 years ago

I'm building this with master meta-browser and master meta-clang at the moment. There is a conflict with meta-intel's LLVM sources bbappend that I'm masking out for my test.

I am quite concerned that having the repo in this state means that it is not possible to update to Chromium to, for example, 92.0.4515.131 to pick up CVE fixes (there are 8 high severity fixes in that release). While we're on Hardknott, I also think that abandoning support for the current LTS release is questionable.

msisov commented 3 years ago

Same problem happens with dunfell branch, btw.

r1mikey commented 3 years ago

Hardknott, which has GCC 10.2.0, hits this error when using meta-browser master and meta-clang master - we're not doing anything sneaky with compilers or appends, but somehow we're using clang++ with libstdc++?:

../../third_party/breakpad/breakpad/src/client/linux/handler/exception_handler.cc:141:41: error: no matching function for call to 'max'
  static const unsigned kSigStackSize = std::max(static_cast<long>(16384), SIGSTKSZ);
                                        ^~~~~~~~
/data/users/r1mikey/yocto-build/machine-build/tmp/work/corei7-64-machine-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot/usr/lib/x86_64-distro-linux/10.2.0/../../../include/c++/10.2.0/bits/algorithmfwd.h:407:5: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('long' vs. 'int')
    max(const _Tp&, const _Tp&);
    ^
/data/users/r1mikey/yocto-build/machine-build/tmp/work/corei7-64-machine-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot/usr/lib/x86_64-distro-linux/10.2.0/../../../include/c++/10.2.0/bits/stl_algo.h:3486:5: note: candidate template ignored: could not match 'initializer_list<type-parameter-0-0>' against 'long'
    max(initializer_list<_Tp> __l, _Compare __comp)
    ^
/data/users/r1mikey/yocto-build/machine-build/tmp/work/corei7-64-machine-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot/usr/lib/x86_64-distro-linux/10.2.0/../../../include/c++/10.2.0/bits/stl_algo.h:3480:5: note: candidate function template not viable: requires single argument '__l', but 2 arguments were provided
    max(initializer_list<_Tp> __l)
    ^
/data/users/r1mikey/yocto-build/machine-build/tmp/work/corei7-64-machine-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot/usr/lib/x86_64-distro-linux/10.2.0/../../../include/c++/10.2.0/bits/algorithmfwd.h:412:5: note: candidate function template not viable: requires 3 arguments, but 2 were provided
    max(const _Tp&, const _Tp&, _Compare);
    ^
1 error generated.
msisov commented 3 years ago

@r1mikey not sure I understand you, but we haven't been testing gcc builds for quite a long time.

Nevertheless, I'm also seeing that on hardknott with clang.

r1mikey commented 3 years ago

@r1mikey not sure I understand you, but we haven't been testing gcc builds for quite a long time.

Yeah, this was totally unexpected - the build seems to be using libstdc++ headers.

ensc commented 3 years ago

After bringing meta-clang to

commit 527f628b7d9bbfe8d3fbe743e876d30c4545a71a
Author: Khem Raj <raj.khem@gmail.com>
Date:   Sun Aug 1 12:05:37 2021 -0700

    clang: Update to latest 13.x branch

and fixing the std::max issue, build fails with

| python3 "../../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..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/usr/lib                         -L..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/lib                         -Wl,--enable-new-dtags                         -Wl,-rpath-link,..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath-link,..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/lib                         -Wl,-rpath,..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath,..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/lib                         -Wl,-O1 -rtlib=libgcc -unwindlib=libgcc -stdlib=libc++ -lc++abi -rpath ..../work/cortexa53-crypto-mx8mm-fsl-linux/chromium-ozone-wayland/92.0.4515.107-r0/recipe-sysroot-native/usr/lib -o "yocto_native/flatc" -Wl,--start-group @"yocto_native/flatc.rsp"  -Wl,--end-group  -ldl -lpthread -lrt
| ld.lld: error: undefined symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_aux(unsigned long, unsigned long, unsigned long, char)
| >>> referenced by cpp_generator.cc
| >>>               yocto_native/obj/third_party/flatbuffers/compiler_files/cpp_generator.o:(grpc_cpp_generator::PrintIncludes(grpc_generator::Printer*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, grpc_cpp_generator::Parameters const&))
| >>> referenced by cpp_generator.cc
| >>>               yocto_native/obj/third_party/flatbuffers/compiler_files/cpp_generator.o:(grpc_cpp_generator::PrintIncludes(grpc_generator::Printer*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, grpc_cpp_generator::Parameters const&))
| >>> referenced by code_generators.cpp
... [many more] ....

But might be also related to other layers (meta-imx)

(meta-browser at 967f28f0404cef3b74fb9d0d3c897b65b15adcdf before "Convert to new override syntax")

psaavedra commented 3 years ago

This problem is address in meta-clang (branch hardknott) in the commit b0d805060791006d651efd3d7ae3dd5add8f70fe

psaavedra commented 3 years ago

in addition, the latest commits added in master (in meta-browser) are also needed to fix other found issues during the triage:

(see the comment here )