Created attachment 1515 [details]
Disable libpython

It seems this has been done at:

commit d38ad3271829b2d282c973e69edd265ef52174c8
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Fri Jan 14 16:33:05 2011 -0600

    linux-yocto: hard-code NO_LIBPERL/NO_LIBPYTHON
    
    ExtUtils::Embed ccopts is getting the host's -I/usr/local/include and
    using it to compile perf, which results in a compilation error that
    started appearing just recently.
    
    This turns the code that makes use of ExtUtils::Embed off and simply
    hard-codes NO_LIBPERL.
    
    It does the same for LIBPYTHON while we're at it, since it probably
    suffers from a similar underlying problem and just by chance hasn't
    broken anything yet.
    
    This will be re-enabled after I familiarize myself with the perf
    recipe and am able to create a proper fix.
    
    Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

So this fix should be add in meta-fsl-ppc as well?

Perf can be built successfully after disabling LIBPERL and LIBPYTHON, a patch will be submitted for meta-fsl-ppc.

My suggestion is to hit the middle ground, I unfortunately can't test from
here, since fetches are failing and I need to see what's wrong with my
name resolution in the morning.

What I mean is that I have a patch, I'm about to send that does this:

--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -68,6 +68,7 @@ EXTRA_OEMAKE = \
                CC="${CC}" \
                AR="${AR}" \
                perfexecdir=${libexecdir} \
+               EXTRA_CFLAGS="-fno-var-tracking" \
                NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \

To fix build time issues with arm (and even x86), part of the patch 
that we recently did removes the full export of CFLAGS and LDFLAGS
to the perf build, and that's a good thing in my opinion.

But we don't want to fix this by patching the kernel, since that means all
kernel repos need to carry the fix, so my suggestion is to pass what we
used to have: 

  LDFLAGS = "-ldl -lutil"

or at least the -ldl, which is what is missing, to the build via 
EXTRA_CFLAGS, that way we are only extending, not overriding what
the makefiles are defining.

(In reply to comment #4)
> My suggestion is to hit the middle ground, I unfortunately can't test from
> here, since fetches are failing and I need to see what's wrong with my
> name resolution in the morning.
> 
> What I mean is that I have a patch, I'm about to send that does this:
> 
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -68,6 +68,7 @@ EXTRA_OEMAKE = \
>                 CC="${CC}" \
>                 AR="${AR}" \
>                 perfexecdir=${libexecdir} \
> +               EXTRA_CFLAGS="-fno-var-tracking" \
>                 NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \
> 
> To fix build time issues with arm (and even x86), part of the patch 
> that we recently did removes the full export of CFLAGS and LDFLAGS
> to the perf build, and that's a good thing in my opinion.
> 
> But we don't want to fix this by patching the kernel, since that means all
> kernel repos need to carry the fix, so my suggestion is to pass what we
> used to have: 
> 
>   LDFLAGS = "-ldl -lutil"
> 
> or at least the -ldl, which is what is missing, to the build via 
> EXTRA_CFLAGS, that way we are only extending, not overriding what
> the makefiles are defining.

The suggestion makes sense, we can avoid applying the kernel patch in all kernel repos. 

According to my test result on p1022ds, both -ldl and -lutil are required to ensure the build pass. 

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 4a815ff..0ceccc4 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -68,6 +68,7 @@ EXTRA_OEMAKE = \
        CC="${CC}" \
        AR="${AR}" \
        perfexecdir=${libexecdir} \
+        EXTRA_CFLAGS="-fno-var-tracking" \
        NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \
        '

@@ -86,15 +87,17 @@ EXTRA_OEMAKE += "\

 PARALLEL_MAKE = ""

+LDFLAGS="-ldl -lutil"
+
 do_compile() {
    # Linux kernel build system is expected to do the right thing
-   unset CFLAGS LDFLAGS
+   unset CFLAGS
    oe_runmake all
 }

 do_install() {
    # Linux kernel build system is expected to do the right thing
-   unset CFLAGS LDFLAGS
+   unset CFLAGS
    oe_runmake DESTDIR=${D} install
    # we are checking for this make target to be compatible with older perf versions
    if [ "${@perf_feature_enabled('perf-scripting', 1, 0, d)}" = "1" -a $(grep install-python_ext ${S}/tools/perf/Makefile) = "0"]; then

(In reply to comment #5)
> (In reply to comment #4)
> > My suggestion is to hit the middle ground, I unfortunately can't test from
> > here, since fetches are failing and I need to see what's wrong with my
> > name resolution in the morning.
> > 
> > What I mean is that I have a patch, I'm about to send that does this:
> > 
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -68,6 +68,7 @@ EXTRA_OEMAKE = \
> >                 CC="${CC}" \
> >                 AR="${AR}" \
> >                 perfexecdir=${libexecdir} \
> > +               EXTRA_CFLAGS="-fno-var-tracking" \
> >                 NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \
> > 
> > To fix build time issues with arm (and even x86), part of the patch 
> > that we recently did removes the full export of CFLAGS and LDFLAGS
> > to the perf build, and that's a good thing in my opinion.
> > 
> > But we don't want to fix this by patching the kernel, since that means all
> > kernel repos need to carry the fix, so my suggestion is to pass what we
> > used to have: 
> > 
> >   LDFLAGS = "-ldl -lutil"
> > 
> > or at least the -ldl, which is what is missing, to the build via 
> > EXTRA_CFLAGS, that way we are only extending, not overriding what
> > the makefiles are defining.
> 
> The suggestion makes sense, we can avoid applying the kernel patch in all
> kernel repos. 
> 
> According to my test result on p1022ds, both -ldl and -lutil are required to
> ensure the build pass. 
> 
> diff --git a/meta/recipes-kernel/perf/perf.bb
> b/meta/recipes-kernel/perf/perf.bb
> index 4a815ff..0ceccc4 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -68,6 +68,7 @@ EXTRA_OEMAKE = \
>         CC="${CC}" \
>         AR="${AR}" \
>         perfexecdir=${libexecdir} \
> +        EXTRA_CFLAGS="-fno-var-tracking" \
>         NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \
>         '
> 
> @@ -86,15 +87,17 @@ EXTRA_OEMAKE += "\
> 
>  PARALLEL_MAKE = ""
> 
> +LDFLAGS="-ldl -lutil"
> +
>  do_compile() {
>     # Linux kernel build system is expected to do the right thing
> -   unset CFLAGS LDFLAGS
> +   unset CFLAGS
>     oe_runmake all
>  }
> 
>  do_install() {
>     # Linux kernel build system is expected to do the right thing
> -   unset CFLAGS LDFLAGS
> +   unset CFLAGS
>     oe_runmake DESTDIR=${D} install
>     # we are checking for this make target to be compatible with older perf
> versions
>     if [ "${@perf_feature_enabled('perf-scripting', 1, 0, d)}" = "1" -a
> $(grep install-python_ext ${S}/tools/perf/Makefile) = "0"]; then


Great news. Thanks for the update and testing.

Otavio, can you confirm if your build continues to work with the changes listed above ?

Created attachment 1517 [details]
Proposed patch

Bruce found that we don't have EXTRA_LDFLAGS (as it would be expected) so I went and prepared a patch to re-add LDFLAGS and included a comment in the code so someone looking at it knows why it is there.

I am building it using 3.11 and if it works will send the patch.

I built it fine in imx23evk (with 3.11 kernel). I sent it to OE-Core for review.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=99b41732458871080cfa7a9bad3f8dfe03e026be