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