**** BEGIN LOGGING AT Sat Oct 27 03:00:01 2018 Oct 27 07:06:01 my recipe has cmake based components and it is looking for clang-4.0, which not able to find. I cloned meta-clang which has clang-7. I tired modifying CMakeLists.txt to add clang-7.0, but same issue. it gives CLANG not found. Oct 27 07:06:11 if(NOT DEFINED CLANG) 158 find_program(CLANG NAMES clang-4.0) 159 if("${CLANG}" STREQUAL "CLANG-NOTFOUND" ) 160 message(FATAL_ERROR "${CMAKE_CURRENT_LIST_FILE}: clang-4.0 not found") 161 endif() endif() Oct 27 07:06:29 any suggestion. Oct 27 07:58:08 khem, gm Oct 27 07:59:21 doing experiments I have aded TOOLCHAIN = "clang" to kernel-selftest Oct 27 07:59:42 supposing then to use llvm-tools Oct 27 08:00:13 but now libcxx fails even to configure on qemuarm Oct 27 08:01:33 /usr/lib//arm-oe-linux-musleabi/8.2.0/../../../include/c++/8.2.0/atomic:250: und Oct 27 08:01:33 efined reference to `__atomic_load_4' Oct 27 08:01:40 atomic again Oct 27 08:02:36 oh, and scary msg like Oct 27 08:02:38 | -- Warning: Did not find file Compiler/-ASM Oct 27 08:02:58 I'll rebuild for scratch, something seems broken Oct 27 14:54:55 ankit: your recipe seems to hard bind to clang4 I think you should take a look into its cmakefiles sometimes packages have hard dependencies on version specific APIs Oct 27 14:55:51 ant_home: yes, libcxx might need to link with libatomic for armv5 Oct 27 14:57:22 ant_home: I think for kernel self-test we should probably ask user to install clang+llvm on his build host and then add HOSTTOOLS += "clang llc" in local.conf Oct 27 14:58:06 another option is to just limit the kernel-selftest recipe to just x86/x86_64 for now Oct 27 14:58:23 I dont see it working reliably on non-x86 arches Oct 27 15:38:58 @khem, I modified and cmakefiles to consider clang 7 as well as clang 4 and above but still same issue. Oct 27 15:40:00 it must be having errors in CMakeErrors.txt file Oct 27 15:40:30 if its still looking for clang-4.0 then you havent really fixed it Oct 27 15:40:41 maybe you can just drop the version string Oct 27 15:40:51 just let it look for clang Oct 27 15:41:10 let me check that, but it works fine on Ubutu distro. Oct 27 15:41:35 what clang version do you have on ubuntu Oct 27 15:41:40 is there a way I can export CLANG path in recipe Oct 27 15:42:03 ubuntu has clang-4.0 Oct 27 15:42:31 yes and the package is expecting same so it will work Oct 27 15:42:52 this seems its written in non portable way Oct 27 15:43:02 so you need to break those assumptions Oct 27 15:44:54 There is CLANG var define in cmakefile. if var is not define, it will look for clang different version in syspath... So just thinking, export of CLANG var should help. Oct 27 15:46:03 what should it point to Oct 27 15:46:11 it is lookin for sources of clang ? Oct 27 15:46:15 or for binaries Oct 27 15:46:36 binaries Oct 27 15:46:39 you can set EXTRA_OECMAKE = "-DCLANG=clang" in recipe Oct 27 15:47:22 Thanks, let me check. :) Oct 27 19:45:35 khem, I'd just add PACKAGECONFIG_remove_arm = "bpf" Oct 27 19:45:51 dunno runtime, though Oct 27 19:46:27 (I have hard time imaging the 32 bit kernel (or JIT?) swallowing the bpf 64bit objects Oct 27 19:46:34 ...) Oct 27 19:46:55 builds is fixed, if you think I'll send the patch Oct 27 20:26:20 lot of compiler warnings btw Oct 27 20:59:46 well, only two recipes failing in world build for qemuarm now Oct 27 21:00:06 android-tools seems to be JaMa's matter Oct 27 21:00:44 so there is 'just' the little ecipes-qt/qt5/qtwebkit_git.bb:do_compile to fix Oct 27 21:01:11 yawn Oct 27 21:01:16 maybe tomorrow **** ENDING LOGGING AT Sun Oct 28 02:59:59 2018