On Wed, Sep 23, 2026 at 12:14 PM Richard Purdie via lists.openembedded.org <[email protected]> wrote:
> On Wed, 2026-09-23 at 14:54 +0000, Peter Marko via lists.openembedded.org > 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. > > This sounds very familiar. > > > https://git.openembedded.org/openembedded-core/commit/?id=d18bf7fa8e80d6cfaf3fdbe1ab06eec84b954432 > > Basically we link with -Wl,--allow-shlib-undefined and then by the time > we run it, we have the uninative glibc available which will have the > missing symbols. > > I think the failing case gtest links libstdc++ statically, and it inherits the undefined symbols which can not be resolved. it might solve it I am not sure > Cheers, > > Richard > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246558): https://lists.openembedded.org/g/openembedded-core/message/246558 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]] -=-=-=-=-=-=-=-=-=-=-=-
