Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

["Khem Raj" <raj.khem@gmail.com>]

On 5/28/20 6:20 AM, Richard Purdie wrote:
> On Wed, 2020-05-27 at 19:11 -0400, Denys Dmytriyenko wrote:
>> On Wed, May 27, 2020 at 10:25:31PM +0100, Richard Purdie wrote:
>>> On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote:
>>>> On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote:
>>>>> asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1
>>>>> )
>>>>> this helps in using common header across multiple versions of
>>>>> kernel
>>>>> going back
>>>>
>>>> This check should have been there from the beginning and for
>>>> every
>>>> header
>>>> file. It's big PITA to sync this list up, especially when dealing
>>>> with
>>>> different glibc or kernel than OE-Core, e.g. external toolchains,
>>>> etc.
>>>>
>>>> Any objections to making this check more generic for every entry
>>>> in
>>>> the list?
>>>
>>> Yes, a strong objection. We don't want to support or encourage
>>> every
>>> kernel version out there.
>>>
>>> I also don't understand why people need to change the libc-headers
>>> anyway :(
>>
>> I already explained my use-case with external toolchains - those
>> usually come
>> with specific set of libc-headers. And when those don't match the
>> list from
>> OE-Core, it causes problems, trying to support some resemblance of
>> multilib.
>> I believe that got disabled completely now for external-toolchains
>> anyway...
> 
> Right, external toolchains I can understand having specific version
> requirements. What I don't really understand is external toolchains
> would come with their own headers in most cases I can think of?
> 

this is not a freestanding toolchain, but hosted one, so they need to 
provide OS (linux) headers. think of case where apps are build just by
using this toolchain outside OE, app devs are not expected to provide 
these headers.

> Cheers,
> 
> Richard
> 
>