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

[Khem Raj]

On Wed, Mar 9, 2011 at 11:58 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> 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.

Yes thats probably better

 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.
>

usually if a patch has reviews that needs retouching it. It should go
back through the same cycle it went first time
which was my assumption here which obviously was not case here. the
patches to oe-core from yocto
I assumed were proposed through the branch to pull from and I think is
a good way to prune errors as patches move into
oe-core

> 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.

Yes bisection is important. I guess I assumed too much even though I
was verifying
We need to have openembedded-core-contrib setup for people who do not
have possibility to use yocto-contrib