[OE-core] [PATCH 1/1] gcc-runtime: fix LSB library checks for libstdc++.so.6

[Richard Purdie]

On Tue, 2011-03-08 at 20:54 -0800, Khem Raj wrote:
> On 3/8/2011 5:26 PM, Nitin A Kamble wrote:
> > From: Nitin A Kamble<nitin.a.kamble at intel.com>
> >
> > [YOCTO #795]
> >
> > When we run library check of LSB on qemux86 and qemuppc, we got some failures
> > about 'libstdc++.so.6'.
> >
> > Test environment:
> > Platform: Qemu-x86, Qemu-ppc
> > lsb image: poky-image-lsb-qemux86-test.ext3(Feb 26th, auto-build server)
> > Library check of LSB: 4.1.0-1
> >
> > The error log:
> > Did not find _ZNKSt5ctypeIcE8do_widenEPKcS2_Pc (GLIBCXX_3.4) in libstdc++.so.6
> > Unmangled symbol name: std::ctype<char>::do_widen(char const*, char const*,
> > char*) const
> > ...
> >
> >   found that some weak symbols ('W') change into local ('t') during link time
> > and be stripped. According to compiling log, the option
> > "-fvisibility-inlines-hidden" is used for gcc. And this option caused some weak
> > symbols change into local.
> >
> > see http://bugzilla.pokylinux.org/show_bug.cgi?id=795 for more information on the bug.
> >
> > Signed-off-by: Nitin A Kamble<nitin.a.kamble at intel.com>
> > Signed-off-by: Jingdong Lu<jingdong.lu at windriver.com>
> > Signed-off-by: Khem Raj<raj.khem at gmail.com>
> 
> thank you. Applied it to openembedded-core

This raises some questions about how the pull model works as I'd been
holding off the python RDEPENDS change until I'd had time to check
something out yet you've applied it. I haven't had the time to be able
to make any informed feedback on the patch yet whether it was ok or not
and being able to give any informed feedback takes time.

My basic concern that that the RDEPENDS shouldn't be having that effect
on native packages and it if it, we probably have a bug somewhere else
that likely needs fixing.

So the question is whether we are going truly for the pull model, who
are the people top of tree, what code review applies to patches from
those people, how absence might get handled and so forth.

As an illustration, it would have been much more useful for me if
someone had pulled the individual patches together into a single git
branch and presented that. This helps me as it highlights the
outstanding patches and is what Saul does with many of the Yocto
patches.

I'm aware there are a few patches pending review and I'm thinking the
best approach may be some kind of staging/-next type branch where we
keep these as we review and then either accept, reject or ask for
improvements.

One other thing I noticed is that Khem merged a patch known to be broken
and then a fixup for it several commits later. I don't like to do that
for known breakage since it means things are not bisectable and in that
case I'd have squashed the changes with an update to the commit message
about the change. Its not a major issue but something to keep in mind
going forwards.

Cheers,

Richard