Open psaavedra opened 3 years ago
Apparently this dependency block is addressed later in meta-clang (master, but not for the hardknott
branch):
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"
@kraj can you take a look at this?
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.
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?
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?
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"
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.
Same problem happens with dunfell branch, btw.
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.
@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 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.
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")
This problem is address in meta-clang
(branch hardknott) in the commit b0d805060791006d651efd3d7ae3dd5add8f70fe
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 )
This error was introduced by https://github.com/OSSystems/meta-browser/commit/967f28f0404cef3b74fb9d0d3c897b65b15adcdf in combination with
TCLIBC=glibc
(default setting) andRUNTIME ="llvm"
(established bymeta-browser/meta-chromium/recipes-browser/chromium/chromium.inc:25
):and
Environment: