On Wed, Sep 23, 2026 at 7:54 AM Peter Marko via lists.openembedded.org
<[email protected]> wrote:
> Dear Yocto toolchain experts,
>
>
>
> we have come across a problem with C++ native libraries and sstate-cache
> reuse on different host distros under uninative.
>
>
>
> Our scenario:
>
> For generation of sstate-cache, we're using only x86-64 Debian machines,
> each Yocto branch on a fixed version.
>
> For example for wrynose we use Debian 13.
>
> However, the clients can have a different host distro (different Debian
> release or even Ubuntu or Fedora).
>
> I think this is how Yocto uninative sstate-cache is intended to be used.
>
>
>
> The problem is following:
>
> GCC version is different between different Host distros, especially
> libstdc++ from newer GCC has more symbols than from older GCC.
>
> So when re-using a native c++ library generated on Debian-13, Debian-12
> liker can report failures.
>
> Concrete case we experienced is linking against googletest-native and
> missing symbol __cxa_call_terminate (introduced in GCC 14) on Debian 12
> (GCC 12.2.0).
>
>
>
> We don't want to go away from uninative as that would force us to produce
> separate sstate-cache for each host distro and explode storage size and
> build times.
>
>
>
> Has anyone else come across this problem?
>
> What would be the recommended way to solve this?
>
>
>
> Could libstdc++ be included in uninative?
>
> Would that work with all the different GCC versions in all supported host
> distros?
>
>
>
> Or some magical compiler option we could use to disable usage of some
> newer symbols?
>
>
>
> I know that we could use buildtools tarball, however that's against the
> idea of running Yocto natively.
>
> It's also a step very easy to be forgotten during build setup unless there
> is some magical qa check for that.
>
> And for application developers it's yet another Yocto obstacle and
> argument against developing with Yocto.
>
>
>
uninative only makes glibc (and libgcc_s) universal. libstdc++ is
still taken from the host, both when linking and at runtime. Native C++
artefacts are therefore only portable to hosts whose libstdc++ is at least
as new as the one on the machine that built the sstate.
It is wider than googletest. Any C++ source that includes <iostream> and is
built with gcc >= 13
references std::ios_base_library_init()@GLIBCXX_3.4.32. For example, a
cmake-native built on a gcc 13+ host needs GLIBCXX_3.4.32, while
Debian 12's libstdc++ (gcc 12) stops at 3.4.30. So I would expect
Debian 13 generated sstate to also break prebuilt native C++ tools on
Debian 12 at runtime ("version `GLIBCXX_3.4.32' not found"), not just
gtest at link time. You can check with:
objdump -T <native-binary> | grep -o 'GLIBCXX_[0-9.]*' | sort -uV |
tail -1
googletest-native is built as a static library by default, so libgtest.a
and libgmock.a carry an unversioned reference to __cxa_call_terminate,
which is resolved against the old libstdc++ when the consuming recipe
links on the client. uninative's -Wl,--allow-shlib-undefined does not
help here since it only covers shared libraries. I can reproduce it with
a plain Release build of googletest 1.18 on a recent gcc.
There is no compiler option that can come to rescue here sadly.
somethings to consider
a) Generate the shared sstate on the oldest host gcc you want to support.
libstdc++ is backward compatible, so objects built with gcc 12 link and
run fine against newer libstdc++. This is the old "build on the oldest
distro" rule, which uninative removed for glibc but not for libstdc++.
Only native/cross output changes; with hash equivalence, target sstate
is still reused. This is what I would do right away.
b) Add an early check, which covers the "easy to forget" part. A small
class in your distro config can find the highest GLIBCXX_/CXXABI_
version in the host libstdc++ (g++ -print-file-name=libstdc++.so.6) and
stop the build with a clear message when it is older than what your
sstate needs, e.g. suggesting a newer gcc or buildtools-extended. That
turns an obscure link or runtime failure into one clear message.
c) Ship libstdc++ in uninative. This is technically feasible, libgcc was
added
to uninative in 2023 for a similar mismatch,
and the uninative loader already prefers its own libraries over the
host's ld.so.cache. It would work for all hosts whose gcc is not newer
than the libstdc++ that uninative ships (gcc 16 on master today), with
two caveats:
- It needs a UNINATIVE_MAXGLIBCVERSION-style check for gcc, so that it is
disabled on hosts (e.g. rolling distros) that have a newer gcc. We
have already seen libstdc++ ABI changes between gcc point releases
(13.1 -> 13.2).
- It must apply at link time as well as at runtime, because static
archives like libgtest.a are resolved when the consuming recipe links.
BUILD_LDFLAGS would need a -L pointing at a directory that holds only
uninative's libstdc++.so, so it takes precedence over the host gcc's.
This needs changes to uninative-tarball.bb and uninative.bbclass plus a
new uninative release, so it should be discussed on the OE-Core list.
I think it is the only option that keeps "one universal native sstate"
true for C++, and I would be happy to help prototype it.
d) Include the host libstdc++ level in the signatures of native tasks, so
that mismatched hosts rebuild instead of failing. With hash equivalence
you would end up with one native sstate set per gcc level, not per
distro. It is more robust than (a) but costs rebuilds on the clients.
For wrynose today, I would suggest (a) + (b), and raising (c) on the
OE-Core list as the long-term fix.
Cheers,
-Khem
> Best Regards,
>
> Peter
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246537):
https://lists.openembedded.org/g/openembedded-core/message/246537
Mute This Topic: https://lists.openembedded.org/mt/121393863/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
