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

login
register
mail settings
Submitter Matthew McClintock
Date Aug. 21, 2012, 4:20 p.m.
Message ID <1345566017-15508-1-git-send-email-msm@freescale.com>
Download mbox | patch
Permalink /patch/35065/
State New
Headers show

Comments

Matthew McClintock - Aug. 21, 2012, 4:20 p.m.
kmod will fail to build with the following error because O_CLOEXEC is
not defined:

| libkmod/libkmod-module.c: In function 'kmod_module_get_initstate':
| libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in this function)
| libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is reported only once
| libkmod/libkmod-module.c:1640: error: for each function it appears in.)
| libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt':
| libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in this function)
| libkmod/libkmod-module.c: In function 'kmod_module_get_sections':
| libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in this function)
| libkmod/libkmod-file.c: In function 'kmod_file_open':
| libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in this function)
| libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported only once
| libkmod/libkmod-file.c:282: error: for each function it appears in.)

Since we are only using kmod-native for depmod, and it's a non-threaded
user of this libary being built this should be safe to override O_CLOEXEC.

Keep in mind this is ONLY effecting the native builds and not what is
being shipped in the root file system.

Signed-off-by: Matthew McClintock <msm@freescale.com>
---
 meta/recipes-kernel/kmod/kmod-native_git.bb |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
Khem Raj - Aug. 21, 2012, 5:54 p.m.
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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
McClintock Matthew-B29882 - Aug. 21, 2012, 5:59 p.m.
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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.

-M
Khem Raj - Aug. 21, 2012, 6:06 p.m.
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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
and furthermore it if it comes from fcntl.h which is not where you are
looking for
there are few variables like that where its impacting more than
affected systems.


>
> -M
McClintock Matthew-B29882 - Aug. 21, 2012, 6:10 p.m.
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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?

> there are few variables like that where its impacting more than
> affected systems.

I don't follow...

-M
Khem Raj - Aug. 21, 2012, 6:30 p.m.
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>> <B29882@freescale.com> wrote:
>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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

>
>> there are few variables like that where its impacting more than
>> affected systems.
>
> I don't follow...
>
> -M
Saul Wold - Aug. 21, 2012, 6:41 p.m.
On 08/21/2012 11:30 AM, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>> <B29882@freescale.com> wrote:
>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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.

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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
McClintock Matthew-B29882 - Aug. 21, 2012, 6:46 p.m.
On Tue, Aug 21, 2012 at 1:41 PM, Saul Wold <sgw@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@freescale.com> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>>> <B29882@freescale.com> wrote:
>>>>>
>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>>>>> <msm@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.

Then we had a bit more analysis and discussion on the issue and others
chimed in they had implemented similar work arounds... it's all in
that thread.

-M

>
>
>>>
>>>> there are few variables like that where its impacting more than
>>>> affected systems.
>>>
>>>
>>> I don't follow...
>>>
>>> -M
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
McClintock Matthew-B29882 - Aug. 21, 2012, 6:47 p.m.
On Tue, Aug 21, 2012 at 1:30 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>> <B29882@freescale.com> wrote:
>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@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

Well this is seemingly the same way of doing it, just looks like you
always want it applied? I don't think it should always be applied.

If this was it takes to get the build fix in, then I will do it...
please confirm what will be accepted.

-M

>
>>
>>> there are few variables like that where its impacting more than
>>> affected systems.
>>
>> I don't follow...
>>
>> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - Aug. 21, 2012, 6:48 p.m.
On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@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@freescale.com> wrote:
>>>
>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>>> <B29882@freescale.com> wrote:
>>>>>
>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>>>>> <msm@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@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>
Chris Larson - Aug. 21, 2012, 7:02 p.m.
On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@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@freescale.com> wrote:
>>>>
>>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>
>>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>>>> <B29882@freescale.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>>>>>> <msm@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

This does seem like a nicer approach.
McClintock Matthew-B29882 - Aug. 21, 2012, 7:11 p.m.
On Tue, Aug 21, 2012 at 2:02 PM, Chris Larson <clarson@kergoth.com> wrote:
> On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@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@freescale.com> wrote:
>>>>>
>>>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882
>>>>>> <B29882@freescale.com> wrote:
>>>>>>>
>>>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock
>>>>>>>> <msm@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
>
> This does seem like a nicer approach.

OK - 2v1 ;) I'll respin as a patch.

-M
Chris Larson - Aug. 21, 2012, 7:13 p.m.
On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
>> #ifndef O_CLOEXEC
>> # define O_CLOEXEC 0
>> #endif
>>
>> and be done with it
>
> Well this is seemingly the same way of doing it, just looks like you
> always want it applied? I don't think it should always be applied.
>
> If this was it takes to get the build fix in, then I will do it...
> please confirm what will be accepted.

No, on newer systems O_CLOEXEC will be defined, so that #ifndef block
will never be entered, and there'll be no change.
McClintock Matthew-B29882 - Aug. 21, 2012, 7:15 p.m.
On Tue, Aug 21, 2012 at 2:13 PM, Chris Larson <clarson@kergoth.com> wrote:
> On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>>> #ifndef O_CLOEXEC
>>> # define O_CLOEXEC 0
>>> #endif
>>>
>>> and be done with it
>>
>> Well this is seemingly the same way of doing it, just looks like you
>> always want it applied? I don't think it should always be applied.
>>
>> If this was it takes to get the build fix in, then I will do it...
>> please confirm what will be accepted.
>
> No, on newer systems O_CLOEXEC will be defined, so that #ifndef block
> will never be entered, and there'll be no change.

Right, I was not thinking...

-M

Patch

diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb b/meta/recipes-kernel/kmod/kmod-native_git.bb
index 96de8b8..4558c7b 100644
--- a/meta/recipes-kernel/kmod/kmod-native_git.bb
+++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
@@ -4,7 +4,7 @@ 
 require kmod.inc
 inherit native
 
-PR = "${INC_PR}.0"
+PR = "${INC_PR}.1"
 
 do_install_append (){
 	for tool in depmod insmod lsmod modinfo modprobe rmmod
@@ -12,3 +12,9 @@  do_install_append (){
 		ln -s kmod ${D}${bindir}/$tool
 	done
 }
+
+do_configure_prepend (){
+	if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then
+		export CFLAGS="$CFLAGS -D O_CLOEXEC=0"
+	fi
+}