[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