[OE-core] [PATCH v2] kmod-native_git.bb: fix builds for hosts with older libc

Khem Raj raj.khem at gmail.com
Tue Aug 21 18:48:02 UTC 2012


On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw at linux.intel.com> wrote:
> On 08/21/2012 11:30 AM, Khem Raj wrote:
>>
>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
>> <B29882 at freescale.com> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>>
>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>>> <B29882 at freescale.com> wrote:
>>>>>
>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>>>>> <msm at freescale.com> wrote:
>>>>>>>
>>>>>>> +
>>>>>>> +do_configure_prepend (){
>>>>>>> +       if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h;
>>>>>>> then
>>>>>>> +               export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
>>>>>>> +       fi
>>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>>> IMO It would be safer to create a patch for kmod itself where you
>>>>>> define O_CLOEXEC if it
>>>>>> was not defined before. The above seems a bit risky
>>>>>
>>>>>
>>>>> Why is it risky? I only wanted to do this for affected systems. There
>>>>> is not an easy way to do this with a patch, unless of course I apply
>>>>> the patch manually.
>>>>
>>>>
>>>> manually gripping at the host installation and then if O_CLOEXEC might
>>>> be in comments
>>>
>>>
>>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h
>>>
>>>> and furthermore it if it comes from fcntl.h which is not where you are
>>>> looking for
>>>
>>>
>>> I am grepping this file though?
>>
>>
>> I would go into the specific file where its asking for O_CLOEXEC
>>
>> and add
>>
>> #ifndef O_CLOEXEC
>> # define O_CLOEXEC 0
>> #endif
>>
>> and be done with it
>>
> Wasn't this proposed back a month ago:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html
>
> And there was discussion about that approach then? I think it was rejected
> due to lack of testing.

I think if it worked fine on a system like cents 5.8 then that would
cover the case
as well try it on newer systems where O_CLOEXEC is available that should do it.

>
> Sau!
>
>>>
>>>> there are few variables like that where its impacting more than
>>>> affected systems.
>>>
>>>
>>> I don't follow...
>>>
>>> -M
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>




More information about the Openembedded-core mailing list