[PATCH] linux-yocto-3.4: Disable extra slang header search path

[PATCH] linux-yocto-3.4: Disable extra slang header search path

[Richard Purdie]

Add in a workaround to avoid host infection detection build failures
from the slang include directory in perf. I'll defer to Bruce to
fix this properly but we need a workaround now as this is breaking
builds.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/recipes-kernel/linux/linux-yocto/noslang.patch b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
new file mode 100644
index 0000000..9cada34
--- a/dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
@@ -0,0 +1,20 @@
+We (OE) install slang into /usr/include so we never need to look into 
+/usr/include/slang/. We never want to look into a hardcoded path like this
+since it triggers host infection issues. For now, simply remove this
+since it causes us problems.
+
+Upstream-Status: Pending (would need rework)
+
+Index: tools/perf/Makefile
+===================================================================
+--- linux.orig/tools/perf/Makefile	2012-08-07 10:29:43.020149620 +0000
++++ linux/tools/perf/Makefile	2012-08-07 10:30:08.128148098 +0000
+@@ -504,7 +504,7 @@
+ 		BASIC_CFLAGS += -DNO_NEWT_SUPPORT
+ 	else
+ 		# Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
+-		BASIC_CFLAGS += -I/usr/include/slang
++		# BASIC_CFLAGS += -I/usr/include/slang
+ 		EXTLIBS += -lnewt -lslang
+ 		LIB_OBJS += $(OUTPUT)util/ui/setup.o
+ 		LIB_OBJS += $(OUTPUT)util/ui/browser.o
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 48333b3..5ab46b7 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -20,6 +20,8 @@ SRCREV_meta ?= "7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
 
+SRC_URI += "file://noslang.patch"
+
 LINUX_VERSION ?= "3.4.6"
 
 PR = "${INC_PR}.0"

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On Tue, Aug 7, 2012 at 7:17 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Add in a workaround to avoid host infection detection build failures
> from the slang include directory in perf. I'll defer to Bruce to
> fix this properly but we need a workaround now as this is breaking
> builds.

I was out of the office yesterday, so I couldn't check to see if the real fix
for this arrived .. I'll know once I dig out of my email backlog.

Even if I don't have the patch I've been waiting for, I'll pop this
into the tree
and send it out with a pull later today.

Cheers,

Bruce

>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-kernel/linux/linux-yocto/noslang.patch b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
> new file mode 100644
> index 0000000..9cada34
> --- a/dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
> @@ -0,0 +1,20 @@
> +We (OE) install slang into /usr/include so we never need to look into
> +/usr/include/slang/. We never want to look into a hardcoded path like this
> +since it triggers host infection issues. For now, simply remove this
> +since it causes us problems.
> +
> +Upstream-Status: Pending (would need rework)
> +
> +Index: tools/perf/Makefile
> +===================================================================
> +--- linux.orig/tools/perf/Makefile     2012-08-07 10:29:43.020149620 +0000
> ++++ linux/tools/perf/Makefile  2012-08-07 10:30:08.128148098 +0000
> +@@ -504,7 +504,7 @@
> +               BASIC_CFLAGS += -DNO_NEWT_SUPPORT
> +       else
> +               # Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
> +-              BASIC_CFLAGS += -I/usr/include/slang
> ++              # BASIC_CFLAGS += -I/usr/include/slang
> +               EXTLIBS += -lnewt -lslang
> +               LIB_OBJS += $(OUTPUT)util/ui/setup.o
> +               LIB_OBJS += $(OUTPUT)util/ui/browser.o
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> index 48333b3..5ab46b7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> @@ -20,6 +20,8 @@ SRCREV_meta ?= "7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b"
>
>  SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
> +SRC_URI += "file://noslang.patch"
> +
>  LINUX_VERSION ?= "3.4.6"
>
>  PR = "${INC_PR}.0"
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On 12-08-07 07:17 AM, Richard Purdie wrote:
> Add in a workaround to avoid host infection detection build failures
> from the slang include directory in perf. I'll defer to Bruce to
> fix this properly but we need a workaround now as this is breaking
> builds.

I just followed up on a patch from 3 days ago, but I'll follow up here
as well .. just to make sure the message gets through.

We had a pending patch to fix this issue from Liang Li here @ windriver.

Did that patch not fix the problem, or did it fall through the cracks ?

Cheers,

Bruce

>
> Signed-off-by: Richard Purdie<richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-kernel/linux/linux-yocto/noslang.patch b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
> new file mode 100644
> index 0000000..9cada34
> --- a/dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto/noslang.patch
> @@ -0,0 +1,20 @@
> +We (OE) install slang into /usr/include so we never need to look into
> +/usr/include/slang/. We never want to look into a hardcoded path like this
> +since it triggers host infection issues. For now, simply remove this
> +since it causes us problems.
> +
> +Upstream-Status: Pending (would need rework)
> +
> +Index: tools/perf/Makefile
> +===================================================================
> +--- linux.orig/tools/perf/Makefile	2012-08-07 10:29:43.020149620 +0000
> ++++ linux/tools/perf/Makefile	2012-08-07 10:30:08.128148098 +0000
> +@@ -504,7 +504,7 @@
> + 		BASIC_CFLAGS += -DNO_NEWT_SUPPORT
> + 	else
> + 		# Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
> +-		BASIC_CFLAGS += -I/usr/include/slang
> ++		# BASIC_CFLAGS += -I/usr/include/slang
> + 		EXTLIBS += -lnewt -lslang
> + 		LIB_OBJS += $(OUTPUT)util/ui/setup.o
> + 		LIB_OBJS += $(OUTPUT)util/ui/browser.o
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> index 48333b3..5ab46b7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
> @@ -20,6 +20,8 @@ SRCREV_meta ?= "7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b"
>
>   SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
> +SRC_URI += "file://noslang.patch"
> +
>   LINUX_VERSION ?= "3.4.6"
>
>   PR = "${INC_PR}.0"
>
>

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Richard Purdie]

On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
> On 12-08-07 07:17 AM, Richard Purdie wrote:
> > Add in a workaround to avoid host infection detection build failures
> > from the slang include directory in perf. I'll defer to Bruce to
> > fix this properly but we need a workaround now as this is breaking
> > builds.
> 
> I just followed up on a patch from 3 days ago, but I'll follow up here
> as well .. just to make sure the message gets through.
> 
> We had a pending patch to fix this issue from Liang Li here @ windriver.
> 
> Did that patch not fix the problem, or did it fall through the cracks ?

It is not correct. It adds in another search path and just hides the
issue. We should *never* be putting -I/usr/include/slang on the compiler
commandline at all period.

I'd assumed in all the email traffic that this was clear and that
another solution was being worked on that would be acceptable upstream
too.

Perhaps a better option might be: -I=/usr/include/slang ? That assumes
that all kernel gcc versions would accept the = notation, that should be
true by now?

Cheers,

Richard

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On 12-08-07 09:50 AM, Richard Purdie wrote:
> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>> Add in a workaround to avoid host infection detection build failures
>>> from the slang include directory in perf. I'll defer to Bruce to
>>> fix this properly but we need a workaround now as this is breaking
>>> builds.
>>
>> I just followed up on a patch from 3 days ago, but I'll follow up here
>> as well .. just to make sure the message gets through.
>>
>> We had a pending patch to fix this issue from Liang Li here @ windriver.
>>
>> Did that patch not fix the problem, or did it fall through the cracks ?
>
> It is not correct. It adds in another search path and just hides the
> issue. We should *never* be putting -I/usr/include/slang on the compiler
> commandline at all period.

I'd argue that it's more correct than commenting out the upstream
include path.

It fixes the problem, doesn't require a patch to the kernel and give
us time to work upstream and get a real fix.

So I'd really prefer that we take that fix, versus the kernel patch
if it actually fixes the problem.

>
> I'd assumed in all the email traffic that this was clear and that
> another solution was being worked on that would be acceptable upstream
> too.

Exactly what I referred to above. But we don't want a temporary
kernel path, we want the temporary recipe patch.

>
> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
> that all kernel gcc versions would accept the = notation, that should be
> true by now?

Not in my experience when dealing with the upstream kernel and tools,
there are plenty of old compilers floating around.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>
>

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[McClintock Matthew-B29882]

On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>
>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>
>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>
>>>> Add in a workaround to avoid host infection detection build failures
>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>> fix this properly but we need a workaround now as this is breaking
>>>> builds.
>>>
>>>
>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>> as well .. just to make sure the message gets through.
>>>
>>> We had a pending patch to fix this issue from Liang Li here @ windriver.
>>>
>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>
>>
>> It is not correct. It adds in another search path and just hides the
>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>> commandline at all period.
>
>
> I'd argue that it's more correct than commenting out the upstream
> include path.
>
> It fixes the problem, doesn't require a patch to the kernel and give
> us time to work upstream and get a real fix.
>
> So I'd really prefer that we take that fix, versus the kernel patch
> if it actually fixes the problem.
>
>
>>
>> I'd assumed in all the email traffic that this was clear and that
>> another solution was being worked on that would be acceptable upstream
>> too.
>
>
> Exactly what I referred to above. But we don't want a temporary
> kernel path, we want the temporary recipe patch.
>
>
>>
>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>> that all kernel gcc versions would accept the = notation, that should be
>> true by now?
>
>
> Not in my experience when dealing with the upstream kernel and tools,
> there are plenty of old compilers floating around.

Sorry, I'm not following this thread super close.. will all kernel
trees need to apply this patch? That does not seem ideal...

-M

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
> <bruce.ashfield@windriver.com>  wrote:
>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>
>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>
>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>
>>>>> Add in a workaround to avoid host infection detection build failures
>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>> fix this properly but we need a workaround now as this is breaking
>>>>> builds.
>>>>
>>>>
>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>> as well .. just to make sure the message gets through.
>>>>
>>>> We had a pending patch to fix this issue from Liang Li here @ windriver.
>>>>
>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>
>>>
>>> It is not correct. It adds in another search path and just hides the
>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>> commandline at all period.
>>
>>
>> I'd argue that it's more correct than commenting out the upstream
>> include path.
>>
>> It fixes the problem, doesn't require a patch to the kernel and give
>> us time to work upstream and get a real fix.
>>
>> So I'd really prefer that we take that fix, versus the kernel patch
>> if it actually fixes the problem.
>>
>>
>>>
>>> I'd assumed in all the email traffic that this was clear and that
>>> another solution was being worked on that would be acceptable upstream
>>> too.
>>
>>
>> Exactly what I referred to above. But we don't want a temporary
>> kernel path, we want the temporary recipe patch.
>>
>>
>>>
>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>> that all kernel gcc versions would accept the = notation, that should be
>>> true by now?
>>
>>
>> Not in my experience when dealing with the upstream kernel and tools,
>> there are plenty of old compilers floating around.
>
> Sorry, I'm not following this thread super close.. will all kernel
> trees need to apply this patch? That does not seem ideal...

They would, once we get the patch merged upstream. And you are right,
linux-yocto is easy enough, but that's one set of kernel trees.

The patch that we proposed to the perf recipe would fix it for all
users of that recipe, with a suitable set of kernels (say 3.0 to
3.6 (I haven't checked).

Honestly, that's why we proposed a perf recipe fix, while working on the
right fix for the upstream kernel.

Cheers,

Bruce



>
> -M

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On Tue, Aug 7, 2012 at 10:18 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
>>
>> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
>> <bruce.ashfield@windriver.com>  wrote:
>>>
>>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>>
>>>>
>>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>>
>>>>>
>>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>>
>>>>>>
>>>>>> Add in a workaround to avoid host infection detection build failures
>>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>>> fix this properly but we need a workaround now as this is breaking
>>>>>> builds.
>>>>>
>>>>>
>>>>>
>>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>>> as well .. just to make sure the message gets through.
>>>>>
>>>>> We had a pending patch to fix this issue from Liang Li here @
>>>>> windriver.
>>>>>
>>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>>
>>>>
>>>>
>>>> It is not correct. It adds in another search path and just hides the
>>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>>> commandline at all period.
>>>
>>>
>>>
>>> I'd argue that it's more correct than commenting out the upstream
>>> include path.
>>>
>>> It fixes the problem, doesn't require a patch to the kernel and give
>>> us time to work upstream and get a real fix.
>>>
>>> So I'd really prefer that we take that fix, versus the kernel patch
>>> if it actually fixes the problem.
>>>
>>>
>>>>
>>>> I'd assumed in all the email traffic that this was clear and that
>>>> another solution was being worked on that would be acceptable upstream
>>>> too.
>>>
>>>
>>>
>>> Exactly what I referred to above. But we don't want a temporary
>>> kernel path, we want the temporary recipe patch.
>>>
>>>
>>>>
>>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>>> that all kernel gcc versions would accept the = notation, that should be
>>>> true by now?
>>>
>>>
>>>
>>> Not in my experience when dealing with the upstream kernel and tools,
>>> there are plenty of old compilers floating around.
>>
>>
>> Sorry, I'm not following this thread super close.. will all kernel
>> trees need to apply this patch? That does not seem ideal...
>
>
> They would, once we get the patch merged upstream. And you are right,
> linux-yocto is easy enough, but that's one set of kernel trees.

I should add, that not all trees, and only builds that use a
particular set of perf
features out of master would see this problem (as far as I know), so I didn't
mean to make this sound bigger than it is ... it's just something that master
was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing
the problem as well :)

Cheers,

Bruce

>
> The patch that we proposed to the perf recipe would fix it for all
> users of that recipe, with a suitable set of kernels (say 3.0 to
> 3.6 (I haven't checked).
>
> Honestly, that's why we proposed a perf recipe fix, while working on the
> right fix for the upstream kernel.
>
> Cheers,
>
> Bruce
>
>
>
>
>>
>> -M
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[McClintock Matthew-B29882]

On Tue, Aug 7, 2012 at 9:22 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> On Tue, Aug 7, 2012 at 10:18 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>> On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
>>>
>>> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
>>> <bruce.ashfield@windriver.com>  wrote:
>>>>
>>>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>>>
>>>>>
>>>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>>>
>>>>>>
>>>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>>>
>>>>>>>
>>>>>>> Add in a workaround to avoid host infection detection build failures
>>>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>>>> fix this properly but we need a workaround now as this is breaking
>>>>>>> builds.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>>>> as well .. just to make sure the message gets through.
>>>>>>
>>>>>> We had a pending patch to fix this issue from Liang Li here @
>>>>>> windriver.
>>>>>>
>>>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>>>
>>>>>
>>>>>
>>>>> It is not correct. It adds in another search path and just hides the
>>>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>>>> commandline at all period.
>>>>
>>>>
>>>>
>>>> I'd argue that it's more correct than commenting out the upstream
>>>> include path.
>>>>
>>>> It fixes the problem, doesn't require a patch to the kernel and give
>>>> us time to work upstream and get a real fix.
>>>>
>>>> So I'd really prefer that we take that fix, versus the kernel patch
>>>> if it actually fixes the problem.
>>>>
>>>>
>>>>>
>>>>> I'd assumed in all the email traffic that this was clear and that
>>>>> another solution was being worked on that would be acceptable upstream
>>>>> too.
>>>>
>>>>
>>>>
>>>> Exactly what I referred to above. But we don't want a temporary
>>>> kernel path, we want the temporary recipe patch.
>>>>
>>>>
>>>>>
>>>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>>>> that all kernel gcc versions would accept the = notation, that should be
>>>>> true by now?
>>>>
>>>>
>>>>
>>>> Not in my experience when dealing with the upstream kernel and tools,
>>>> there are plenty of old compilers floating around.
>>>
>>>
>>> Sorry, I'm not following this thread super close.. will all kernel
>>> trees need to apply this patch? That does not seem ideal...
>>
>>
>> They would, once we get the patch merged upstream. And you are right,
>> linux-yocto is easy enough, but that's one set of kernel trees.
>
> I should add, that not all trees, and only builds that use a
> particular set of perf
> features out of master would see this problem (as far as I know), so I didn't
> mean to make this sound bigger than it is ... it's just something that master
> was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing
> the problem as well :)
>
> Cheers,
>
> Bruce
>
>>
>> The patch that we proposed to the perf recipe would fix it for all
>> users of that recipe, with a suitable set of kernels (say 3.0 to
>> 3.6 (I haven't checked).
>>
>> Honestly, that's why we proposed a perf recipe fix, while working on the
>> right fix for the upstream kernel.

It seems wrong to need a kernel patch to fix this issue, kernels are
built outside of oe-core and it seems better to fix things in one
place. By the way, I'm seeing this on our kernel recipe in
meta-fsl-ppc too.

-M

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On Tue, Aug 7, 2012 at 10:25 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Aug 7, 2012 at 9:22 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>> On Tue, Aug 7, 2012 at 10:18 PM, Bruce Ashfield
>> <bruce.ashfield@windriver.com> wrote:
>>> On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
>>>>
>>>> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
>>>> <bruce.ashfield@windriver.com>  wrote:
>>>>>
>>>>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Add in a workaround to avoid host infection detection build failures
>>>>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>>>>> fix this properly but we need a workaround now as this is breaking
>>>>>>>> builds.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>>>>> as well .. just to make sure the message gets through.
>>>>>>>
>>>>>>> We had a pending patch to fix this issue from Liang Li here @
>>>>>>> windriver.
>>>>>>>
>>>>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is not correct. It adds in another search path and just hides the
>>>>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>>>>> commandline at all period.
>>>>>
>>>>>
>>>>>
>>>>> I'd argue that it's more correct than commenting out the upstream
>>>>> include path.
>>>>>
>>>>> It fixes the problem, doesn't require a patch to the kernel and give
>>>>> us time to work upstream and get a real fix.
>>>>>
>>>>> So I'd really prefer that we take that fix, versus the kernel patch
>>>>> if it actually fixes the problem.
>>>>>
>>>>>
>>>>>>
>>>>>> I'd assumed in all the email traffic that this was clear and that
>>>>>> another solution was being worked on that would be acceptable upstream
>>>>>> too.
>>>>>
>>>>>
>>>>>
>>>>> Exactly what I referred to above. But we don't want a temporary
>>>>> kernel path, we want the temporary recipe patch.
>>>>>
>>>>>
>>>>>>
>>>>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>>>>> that all kernel gcc versions would accept the = notation, that should be
>>>>>> true by now?
>>>>>
>>>>>
>>>>>
>>>>> Not in my experience when dealing with the upstream kernel and tools,
>>>>> there are plenty of old compilers floating around.
>>>>
>>>>
>>>> Sorry, I'm not following this thread super close.. will all kernel
>>>> trees need to apply this patch? That does not seem ideal...
>>>
>>>
>>> They would, once we get the patch merged upstream. And you are right,
>>> linux-yocto is easy enough, but that's one set of kernel trees.
>>
>> I should add, that not all trees, and only builds that use a
>> particular set of perf
>> features out of master would see this problem (as far as I know), so I didn't
>> mean to make this sound bigger than it is ... it's just something that master
>> was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing
>> the problem as well :)
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> The patch that we proposed to the perf recipe would fix it for all
>>> users of that recipe, with a suitable set of kernels (say 3.0 to
>>> 3.6 (I haven't checked).
>>>
>>> Honestly, that's why we proposed a perf recipe fix, while working on the
>>> right fix for the upstream kernel.
>
> It seems wrong to need a kernel patch to fix this issue, kernels are
> built outside of oe-core and it seems better to fix things in one
> place. By the way, I'm seeing this on our kernel recipe in
> meta-fsl-ppc too.

Have you tried the patch from Liang Li @ Windriver ? Sent last Friday,
it should solve your
immediate problem .. it solved ours.

Cheers,

Bruce

>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[McClintock Matthew-B29882]

On Tue, Aug 7, 2012 at 9:30 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 10:25 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Aug 7, 2012 at 9:22 PM, Bruce Ashfield
>> <bruce.ashfield@windriver.com> wrote:
>>> On Tue, Aug 7, 2012 at 10:18 PM, Bruce Ashfield
>>> <bruce.ashfield@windriver.com> wrote:
>>>> On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
>>>>>
>>>>> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
>>>>> <bruce.ashfield@windriver.com>  wrote:
>>>>>>
>>>>>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Add in a workaround to avoid host infection detection build failures
>>>>>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>>>>>> fix this properly but we need a workaround now as this is breaking
>>>>>>>>> builds.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>>>>>> as well .. just to make sure the message gets through.
>>>>>>>>
>>>>>>>> We had a pending patch to fix this issue from Liang Li here @
>>>>>>>> windriver.
>>>>>>>>
>>>>>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It is not correct. It adds in another search path and just hides the
>>>>>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>>>>>> commandline at all period.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'd argue that it's more correct than commenting out the upstream
>>>>>> include path.
>>>>>>
>>>>>> It fixes the problem, doesn't require a patch to the kernel and give
>>>>>> us time to work upstream and get a real fix.
>>>>>>
>>>>>> So I'd really prefer that we take that fix, versus the kernel patch
>>>>>> if it actually fixes the problem.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I'd assumed in all the email traffic that this was clear and that
>>>>>>> another solution was being worked on that would be acceptable upstream
>>>>>>> too.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Exactly what I referred to above. But we don't want a temporary
>>>>>> kernel path, we want the temporary recipe patch.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>>>>>> that all kernel gcc versions would accept the = notation, that should be
>>>>>>> true by now?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not in my experience when dealing with the upstream kernel and tools,
>>>>>> there are plenty of old compilers floating around.
>>>>>
>>>>>
>>>>> Sorry, I'm not following this thread super close.. will all kernel
>>>>> trees need to apply this patch? That does not seem ideal...
>>>>
>>>>
>>>> They would, once we get the patch merged upstream. And you are right,
>>>> linux-yocto is easy enough, but that's one set of kernel trees.
>>>
>>> I should add, that not all trees, and only builds that use a
>>> particular set of perf
>>> features out of master would see this problem (as far as I know), so I didn't
>>> mean to make this sound bigger than it is ... it's just something that master
>>> was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing
>>> the problem as well :)
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> The patch that we proposed to the perf recipe would fix it for all
>>>> users of that recipe, with a suitable set of kernels (say 3.0 to
>>>> 3.6 (I haven't checked).
>>>>
>>>> Honestly, that's why we proposed a perf recipe fix, while working on the
>>>> right fix for the upstream kernel.
>>
>> It seems wrong to need a kernel patch to fix this issue, kernels are
>> built outside of oe-core and it seems better to fix things in one
>> place. By the way, I'm seeing this on our kernel recipe in
>> meta-fsl-ppc too.
>
> Have you tried the patch from Liang Li @ Windriver ? Sent last Friday,
> it should solve your
> immediate problem .. it solved ours.

http://patches.openembedded.org/project/oe-core/list/?submitter=5585

which version?

-M

>
> Cheers,
>
> Bruce
>
>>
>> -M
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] linux-yocto-3.4: Disable extra slang header search path

[Bruce Ashfield]

On Thu, Aug 9, 2012 at 3:17 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Aug 7, 2012 at 9:30 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> On Tue, Aug 7, 2012 at 10:25 PM, McClintock Matthew-B29882
>> <B29882@freescale.com> wrote:
>>> On Tue, Aug 7, 2012 at 9:22 PM, Bruce Ashfield
>>> <bruce.ashfield@windriver.com> wrote:
>>>> On Tue, Aug 7, 2012 at 10:18 PM, Bruce Ashfield
>>>> <bruce.ashfield@windriver.com> wrote:
>>>>> On 12-08-07 10:16 PM, McClintock Matthew-B29882 wrote:
>>>>>>
>>>>>> On Tue, Aug 7, 2012 at 8:59 AM, Bruce Ashfield
>>>>>> <bruce.ashfield@windriver.com>  wrote:
>>>>>>>
>>>>>>> On 12-08-07 09:50 AM, Richard Purdie wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 2012-08-07 at 09:24 -0400, Bruce Ashfield wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12-08-07 07:17 AM, Richard Purdie wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Add in a workaround to avoid host infection detection build failures
>>>>>>>>>> from the slang include directory in perf. I'll defer to Bruce to
>>>>>>>>>> fix this properly but we need a workaround now as this is breaking
>>>>>>>>>> builds.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just followed up on a patch from 3 days ago, but I'll follow up here
>>>>>>>>> as well .. just to make sure the message gets through.
>>>>>>>>>
>>>>>>>>> We had a pending patch to fix this issue from Liang Li here @
>>>>>>>>> windriver.
>>>>>>>>>
>>>>>>>>> Did that patch not fix the problem, or did it fall through the cracks ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It is not correct. It adds in another search path and just hides the
>>>>>>>> issue. We should *never* be putting -I/usr/include/slang on the compiler
>>>>>>>> commandline at all period.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'd argue that it's more correct than commenting out the upstream
>>>>>>> include path.
>>>>>>>
>>>>>>> It fixes the problem, doesn't require a patch to the kernel and give
>>>>>>> us time to work upstream and get a real fix.
>>>>>>>
>>>>>>> So I'd really prefer that we take that fix, versus the kernel patch
>>>>>>> if it actually fixes the problem.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I'd assumed in all the email traffic that this was clear and that
>>>>>>>> another solution was being worked on that would be acceptable upstream
>>>>>>>> too.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Exactly what I referred to above. But we don't want a temporary
>>>>>>> kernel path, we want the temporary recipe patch.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps a better option might be: -I=/usr/include/slang ? That assumes
>>>>>>>> that all kernel gcc versions would accept the = notation, that should be
>>>>>>>> true by now?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Not in my experience when dealing with the upstream kernel and tools,
>>>>>>> there are plenty of old compilers floating around.
>>>>>>
>>>>>>
>>>>>> Sorry, I'm not following this thread super close.. will all kernel
>>>>>> trees need to apply this patch? That does not seem ideal...
>>>>>
>>>>>
>>>>> They would, once we get the patch merged upstream. And you are right,
>>>>> linux-yocto is easy enough, but that's one set of kernel trees.
>>>>
>>>> I should add, that not all trees, and only builds that use a
>>>> particular set of perf
>>>> features out of master would see this problem (as far as I know), so I didn't
>>>> mean to make this sound bigger than it is ... it's just something that master
>>>> was hitting on the autobuilders (and who knows, maybe I'm mischaracterizing
>>>> the problem as well :)
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> The patch that we proposed to the perf recipe would fix it for all
>>>>> users of that recipe, with a suitable set of kernels (say 3.0 to
>>>>> 3.6 (I haven't checked).
>>>>>
>>>>> Honestly, that's why we proposed a perf recipe fix, while working on the
>>>>> right fix for the upstream kernel.
>>>
>>> It seems wrong to need a kernel patch to fix this issue, kernels are
>>> built outside of oe-core and it seems better to fix things in one
>>> place. By the way, I'm seeing this on our kernel recipe in
>>> meta-fsl-ppc too.
>>
>> Have you tried the patch from Liang Li @ Windriver ? Sent last Friday,
>> it should solve your
>> immediate problem .. it solved ours.
>
> http://patches.openembedded.org/project/oe-core/list/?submitter=5585

http://patches.openembedded.org/patch/33745/

Bruce

>
> which version?
>
> -M
>
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> -M
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>>
>> _______________________________________________
>> 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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"