Re: Fedora 36 / uninative GLIBCXX 3.4.30

Federico Pellegrin

Thanks for the feedback!

Indeed the check is only on the "ldd --version" output which doesn't account for the libstdc++ and that explains it. As compared to Ubuntu 22.04, Fedora 36 actually has also GCC 12.0.1 as default compiler.

As Martin mentions not sure if there is an easy portable way. He mentions objdump which is for sure effective but maybe complicated and I feel like relies on the filename being guessed (well should be known, the main link at least) and feels a bit overcomplicated (if we need to go that low level in case I'd suggest just to just use "strings" and grep there instead).

Would relying just on the filename be too shaky? I can see here in point 3 of "History" that it would seem quite well defined. Actually I guess if we would just compare the system (which we may be easily able to get it from the link) to uninative oneĀ  maybe would be enough to determine it is newer? Hardcoding the path to (as ie. /usr/lib64/ is probably not nice (ie. for custom toolchains), so maybe we can ask g++ (-print-search-dirs, libraries section) and look in those?
Then not sure if there are some distros/installs that do the insane-isy thing of just installing directly the .so stripping the versions from the name, hopefully not.

I'm not sure using anything from g++ -dumpspecs would be viable if as Martin mentions you may have (ie. ubuntu-2204) a version with new stdc++ but older g++.


Il giorno dom 3 apr 2022 alle ore 16:52 Martin Jansa <martin.jansa@...> ha scritto:
FWIW: the same is happening now with ubuntu-22.04 where libstdc++6 package is now built from gcc-12 sources (even when gcc itself still defaults to gcc-11).

I was trying to add the check in uninative.bbclass, but haven't found easy portable way to detect the version from (other than parsing objdump -x /full/path/to/ output).

On Sun, Apr 3, 2022 at 12:44 PM Richard Purdie <richard.purdie@...> wrote:
On Sun, 2022-04-03 at 09:12 +0200, Federico Pellegrin wrote:
> I've been playing around building a Yocto imagine based on kirkstone/master on
> the just released Fedora 36 beta test image. (just to give a few bits more
> details: builds a MX8X image, works perfectly fine with Fedora 34 and 35 since
> quite some time)
> The first and most obvious thing I've found out is that it is based on a newer
> version of glibcxx (3.4.30) when the very latest uninative available (as far
> as I could see, apologies if I'm wrong) is on 3.4.29, so at some point this
> will break the build (when pzstd is called).
> Of course for the time being I just disabled uninative and the build is going
> on (will report of course should I find something else). I'm not sure (still
> checking this) if that should have happened automatically, but there was
> actually no warning in that sense (maybe because is GLIBCXX and not GLIBC
> itself?)
> But the question is: should I try to contribute that tarball (I will search
> for details, but if there is any good reference more than welcome!) or is it
> something that is likely done by the core team?
> Of course FC36 is still a test distro so there is no surprise it broke, but as
> we are close to Kirkstone release and possibly other distros will get the same
> upgrade, I guess it could be great if we may fix this before that deadline.

Thanks for reporting it. I think to generate the newer version we need gcc 12
which is still in pre-release. We generate the uninative tarball using our own
builds on the autobuilder so until we have gcc 12 recipes there, we can't
generate that.

Once gcc 12 is out, we will release a new uninative (assuming we can update our

I'd like to think the checks in uninative would have noticed the mismatch, we do
have some code there to detect libc version but perhaps not the CXX pieces so
I'd welcome help in adding something for that.



Join to automatically receive all group messages.