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. Best Regards, Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246529): https://lists.openembedded.org/g/openembedded-core/message/246529 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]] -=-=-=-=-=-=-=-=-=-=-=-
