scarthgap: binary incompatibilities between clang 18 and gcc 13 due to changed name mangling for templates with std::enable_if

Describe the bug A Yocto SDK built with CLANGSDK = "1" contains both gcc and clang and they are expected to be binary compatible so that they can both use the libraries from the Yocto SDK. However, in scarthgap this is not the case:

meta-clang scarthgap provides clang 18, which contains a change for name mangling of C++ templates: https://github.com/llvm/llvm-project/issues/85656 which is a difference in behaviour from gcc 13 provided by openembedded-core scarthgap. As a result, libraries built by Yocto scarthgap with gcc may not be usable by clang in the same Yocto SDK.

This issue showed up here specifically with abseil 20240116.2 from meta-openembedded scarthgap, because absl/log/internal/log_message.h uses some templates with explicit instantiations in libabsl_log_internal_message.so which are affected by the clang name mangling change.

To Reproduce Build a Yocto SDK with the following settings:

checkout poky scarthgap, meta-openembedded scarthgap, meta-clang scarthgap
cd poky
. oe-init-build-env
edit bblayers.conf and add .../meta-openembedded/meta-oe and .../meta-clang to BBLAYERS
edit local.conf and append CLANGSDK = "1" and TOOLCHAIN_TARGET_TASK:append = " abseil-cpp"
bitbake core-image-minimal -cpopulate_sdk
install the resulting SDK

Then test with this code snippet:

#include <absl/log/internal/log_message.h>

int main()
{
    absl::log_internal::LogMessage m{"file", 123, absl::LogSeverity::kFatal};
    m << 0;
    return 0;
}

With gcc it can be compiled:

~$ source /opt/poky/5.0.2/environment-setup-core2-64-poky-linux
~$ $CXX -Wall test.cxx -o test -labsl_log_internal_message
~$ $CXX --version
x86_64-poky-linux-g++ (GCC) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But with clang it does not work:

~$ $CLANGCXX -Wall test.cxx -o test -labsl_log_internal_message
/opt/poky/5.0.2/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: /tmp/test-563df3.o: in function `main':
test.cxx:(.text+0x40): undefined reference to `_ZN4absl12lts_2024011612log_internal10LogMessagelsIiTnNSt9enable_ifIXntsr4absl16HasAbslStringifyIT_EE5valueEiE4typeELi0EEERS2_RKS5_'
x86_64-poky-linux-clang++: error: linker command failed with exit code 1 (use -v to see invocation)
~$ $CLANGCXX --version
clang version 18.1.5 (https://git.yoctoproject.org/poky a725df1839a23b11ae1bace531d242bfc1ab98e0)
Target: x86_64-poky-linux
Thread model: posix
InstalledDir: /opt/poky/5.0.2/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux

Expected behavior It should work equally with both gcc and clang which are present in the Yocto SDK.

Additional context A comment in the clang ticket suggests using -fclang-abi-compat=17 as work-around. Would it make sense to add this to the default CLANGCC and CLANGCXX variables in meta-clang? (until gcc is updated and its ABI is the same again, at least regarding this template name mangling issue)

Additionally I'm wondering whether it would be necessary to use the same option when compiling the clang libraries in compiler-rt, compiler-rt-sanitizers, libcxx, libunwind recipes, to ensure that they are compatible.

kraj / meta-clang

scarthgap: binary incompatibilities between clang 18 and gcc 13 due to changed name mangling for templates with std::enable_if #980