[OE-core] [PATCH 4/7] eglibc: ptrace: protect ptrace_peeksiginfo_args from redefintion

Khem Raj raj.khem at gmail.com
Mon Aug 26 21:16:08 UTC 2013


On Aug 26, 2013, at 10:59 AM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:

> On Mon, Aug 26, 2013 at 1:28 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> 
>> On Aug 25, 2013, at 7:46 PM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>> 
>>> A final (maybe .. hopefully!?) thought on this. Do drop this change,
>>> but give me a
>>> few minutes to remove the offending structure from linux-libc-headers_3.10. That
>>> will also protect all users of yocto, regardless of the kernel unless
>>> they provide
>>> their own libc-headers .. and then they are on their own :)
>>> 
>>> That leaves the c library alone, and should buy us time to fix the
>>> offending apps.
>> 
>> this is not again the correct place to fix it. since you will back this out say later
>> when all apps are fixed anyway. If we need to keep it I would rather have the app
>> builds failing and keep it enabled and it should not be the guy who is doing the kernel
>> headers upgrade to fix the whole ecosystem either. So add the headers by all means
>> and leave the old headers in there until the apps work correctly with new headers.
> 
> Whether or not to allow the apps to break, that's a call for Saul and
> Richard. For
> now, this fix works in all cases, and I'm able to build and boot with the 3.10
> kernel and matching headers.
> 
> Given that we are about to hit the M4 freeze, I'd prefer this in now,
> and the apps
> fixed later. We need to get mileage with the matching headers and kernel.
> 
> I think this is a good compromise for the time being, we've had far
> nastier hacks in
> the libc-headers in the past.

It would make it harder to fix this problem in the app if we work is around this way :)
while I see the your urgency of making 3.10 defaults. I don't think we should rush it but  thats
just me


> 
> Bruce
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"




More information about the Openembedded-core mailing list