Patchwork perf: Add LDFLAGS to allow build of old kernels without patching

login
register
mail settings
Submitter Otavio Salvador
Date Sept. 18, 2013, 1:51 p.m.
Message ID <1379512264-8755-1-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/58329/
State Accepted
Commit 99b41732458871080cfa7a9bad3f8dfe03e026be
Headers show

Comments

Otavio Salvador - Sept. 18, 2013, 1:51 p.m.
The LDFLAGS is required or some old kernels fails due missing
symbols and this is preferred than requiring patches to every old
supported kernel.

Fixes [YOCTO: #5221]

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/recipes-kernel/perf/perf.bb | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
Bruce Ashfield - Sept. 18, 2013, 1:58 p.m.
On Wed, Sep 18, 2013 at 9:51 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
>
> Fixes [YOCTO: #5221]
>

Confirmed here as well, I was able to build my perf tests, and the meta-fsl-ppc
ones have been confirmed in the bug, and with Otavio's confirmation here .. we
should be good to go .. I hope :)

Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>

Cheers,

Bruce

> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  meta/recipes-kernel/perf/perf.bb | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
> index 4a815ff..269069f 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -60,6 +60,11 @@ B = "${WORKDIR}/${BPN}-${PV}"
>  SCRIPTING_DEFINES = "${@perf_feature_enabled('perf-scripting', '', 'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
>  TUI_DEFINES = "${@perf_feature_enabled('perf-tui', '', 'NO_NEWT=1',d)}"
>
> +# The LDFLAGS is required or some old kernels fails due missing
> +# symbols and this is preferred than requiring patches to every old
> +# supported kernel.
> +LDFLAGS="-ldl -lutil"
> +
>  EXTRA_OEMAKE = \
>                 '-C ${S}/tools/perf \
>                 O=${B} \
> @@ -88,13 +93,13 @@ PARALLEL_MAKE = ""
>
>  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
> --
> 1.8.4.rc3
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Richard Purdie - Sept. 18, 2013, 2:04 p.m.
On Wed, 2013-09-18 at 10:51 -0300, Otavio Salvador wrote:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
> 
> Fixes [YOCTO: #5221]
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  meta/recipes-kernel/perf/perf.bb | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Doesn't this reintroduce the problem you previously fixed though with
things rebuilding because the flags changed?

Cheers,

Richard





> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
> index 4a815ff..269069f 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -60,6 +60,11 @@ B = "${WORKDIR}/${BPN}-${PV}"
>  SCRIPTING_DEFINES = "${@perf_feature_enabled('perf-scripting', '', 'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
>  TUI_DEFINES = "${@perf_feature_enabled('perf-tui', '', 'NO_NEWT=1',d)}"
>  
> +# The LDFLAGS is required or some old kernels fails due missing
> +# symbols and this is preferred than requiring patches to every old
> +# supported kernel.
> +LDFLAGS="-ldl -lutil"
> +
>  EXTRA_OEMAKE = \
>  		'-C ${S}/tools/perf \
>  		O=${B} \
> @@ -88,13 +93,13 @@ PARALLEL_MAKE = ""
>  
>  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
Bruce Ashfield - Sept. 18, 2013, 2:06 p.m.
On Wed, Sep 18, 2013 at 10:04 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 10:51 -0300, Otavio Salvador wrote:
>> The LDFLAGS is required or some old kernels fails due missing
>> symbols and this is preferred than requiring patches to every old
>> supported kernel.
>>
>> Fixes [YOCTO: #5221]
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>>  meta/recipes-kernel/perf/perf.bb | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> Doesn't this reintroduce the problem you previously fixed though with
> things rebuilding because the flags changed?

I'm doing a test on just that right now, but as far as I can tell, as
long as they
are consistent between the compile and install, we should be fine. It was when
one was clobbered and one wasn't before, that the rebuilds were triggering.

Bruce

>
> Cheers,
>
> Richard
>
>
>
>
>
>> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
>> index 4a815ff..269069f 100644
>> --- a/meta/recipes-kernel/perf/perf.bb
>> +++ b/meta/recipes-kernel/perf/perf.bb
>> @@ -60,6 +60,11 @@ B = "${WORKDIR}/${BPN}-${PV}"
>>  SCRIPTING_DEFINES = "${@perf_feature_enabled('perf-scripting', '', 'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
>>  TUI_DEFINES = "${@perf_feature_enabled('perf-tui', '', 'NO_NEWT=1',d)}"
>>
>> +# The LDFLAGS is required or some old kernels fails due missing
>> +# symbols and this is preferred than requiring patches to every old
>> +# supported kernel.
>> +LDFLAGS="-ldl -lutil"
>> +
>>  EXTRA_OEMAKE = \
>>               '-C ${S}/tools/perf \
>>               O=${B} \
>> @@ -88,13 +93,13 @@ PARALLEL_MAKE = ""
>>
>>  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
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Enrico Scholz - Sept. 18, 2013, 2:25 p.m.
Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org> writes:

> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
> ...
> +LDFLAGS="-ldl -lutil"

What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
usually?  Perhaps, hacks like

----
do_configure_prepend() {
  cat <<"EOF" > ${S}/tools/perf/x.mk
include Makefile
CFLAGS += ${CFLAGS}
LDLAGS += ${LDFLAGS}
EOF
}

EXTRA_OEMAKE = ... -f x.mk
----

would be a better way?


Enrico
Bruce Ashfield - Sept. 18, 2013, 2:39 p.m.
On Wed, Sep 18, 2013 at 10:25 AM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org> writes:
>
>> The LDFLAGS is required or some old kernels fails due missing
>> symbols and this is preferred than requiring patches to every old
>> supported kernel.
>> ...
>> +LDFLAGS="-ldl -lutil"
>
> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
> usually?  Perhaps, hacks like

We don't want to influence the perf build from the build system, unless we
absolutely have to. We want to use the flags and configs that are contained
within the kernel, just as we do with anything from the kernel tree in general.

>
> ----
> do_configure_prepend() {
>   cat <<"EOF" > ${S}/tools/perf/x.mk
> include Makefile
> CFLAGS += ${CFLAGS}
> LDLAGS += ${LDFLAGS}
> EOF
> }
>
> EXTRA_OEMAKE = ... -f x.mk
> ----
>
> would be a better way?

We only want to influence LDFLAGS at the moment, and we'll work to get an
EXTRA_LDFLAGS into the mainline kernel, so creating less scaffolding, versus
more, is what we are shooting for here :)

Bruce

>
>
> Enrico
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Enrico Scholz - Sept. 18, 2013, 3:19 p.m.
Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:

>>> +LDFLAGS="-ldl -lutil"
>>
>> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
>> usually?  Perhaps, hacks like
>
> We don't want to influence the perf build from the build system, unless we
> absolutely have to. We want to use the flags and configs that are contained
> within the kernel, just as we do with anything from the kernel tree in
> general.

Userspace programs should always be built with optimization flags of the
build system.  E.g. it would be wrong when packages override our idea of
optimization (-Os/-O2/-O6), generation of debug symbols or stripping of
debug symbols.

Kernel itself is an exception because it is tied very much to gcc and
its behaviour.  But things like

| CFLAGS = -fno-omit-frame-pointer -ggdb3

in the perf Makefile must be overridable by the build system.



Enrico
Otavio Salvador - Sept. 18, 2013, 3:23 p.m.
On Wed, Sep 18, 2013 at 12:19 PM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> writes:
>
>>>> +LDFLAGS="-ldl -lutil"
>>>
>>> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
>>> usually?  Perhaps, hacks like
>>
>> We don't want to influence the perf build from the build system, unless we
>> absolutely have to. We want to use the flags and configs that are contained
>> within the kernel, just as we do with anything from the kernel tree in
>> general.
>
> Userspace programs should always be built with optimization flags of the
> build system.  E.g. it would be wrong when packages override our idea of
> optimization (-Os/-O2/-O6), generation of debug symbols or stripping of
> debug symbols.
>
> Kernel itself is an exception because it is tied very much to gcc and
> its behaviour.  But things like
>
> | CFLAGS = -fno-omit-frame-pointer -ggdb3
>
> in the perf Makefile must be overridable by the build system.

I don't agree on this. perf is tied to kernel and part of its code so
I think same exception rule apply for it as well.
Enrico Scholz - Sept. 18, 2013, 3:34 p.m.
Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org> writes:

> +# The LDFLAGS is required or some old kernels fails due missing
> +# symbols and this is preferred than requiring patches to every old
> +# supported kernel.
> +LDFLAGS="-ldl -lutil"

LDFLAGS is usually the wrong variable for extra libs (it might conflict
with '-Wl,-as-needed' or lib-grouping).  Adding new libs to perf seems
to require the modification of EXTLIBS because of

| LIBS = -Wl,--whole-archive $(PERFLIBS) -Wl,--no-whole-archive -Wl,--start-group $(EXTLIBS) -Wl,--end-group
| ...
|$(OUTPUT)perf-%: %.o $(PERFLIBS)
|	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)



Enrico
Enrico Scholz - Sept. 18, 2013, 3:44 p.m.
Otavio Salvador <otavio@ossystems.com.br> writes:

> I don't agree on this. perf is tied to kernel and part of its code so
> I think same exception rule apply for it as well.

perf ships with the kernel but is a pure userspace program.  It does not
require any special setup ('make configure'), it links against complex
userspace gui frameworks and uses userspace headers.


Enrico
Bruce Ashfield - Sept. 18, 2013, 3:54 p.m.
On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Otavio Salvador <otavio@ossystems.com.br> writes:
>
>> I don't agree on this. perf is tied to kernel and part of its code so
>> I think same exception rule apply for it as well.
>
> perf ships with the kernel but is a pure userspace program.  It does not
> require any special setup ('make configure'), it links against complex
> userspace gui frameworks and uses userspace headers.

yes, we realize this .. we have a long a complicated history with perf and the
related build issues.

We are stating our general policy, interfere with it's build as little
as possible.
Use extension variables, not clobber variables, etc.

Otherwise, we end up creating our own issues, and have the bugs to prove it :)

Bruce

>
>
> Enrico
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Richard Purdie - Sept. 18, 2013, 4:02 p.m.
On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
> <enrico.scholz@sigma-chemnitz.de> wrote:
> > Otavio Salvador <otavio@ossystems.com.br> writes:
> >
> >> I don't agree on this. perf is tied to kernel and part of its code so
> >> I think same exception rule apply for it as well.
> >
> > perf ships with the kernel but is a pure userspace program.  It does not
> > require any special setup ('make configure'), it links against complex
> > userspace gui frameworks and uses userspace headers.
> 
> yes, we realize this .. we have a long a complicated history with perf and the
> related build issues.
> 
> We are stating our general policy, interfere with it's build as little
> as possible.
> Use extension variables, not clobber variables, etc.
> 
> Otherwise, we end up creating our own issues, and have the bugs to prove it :)

For the record, I do think Enrico does have a valid point here. We do
put things in CFLAGS and LDFLAGS which we expect *all* userspace to be
built with. Things like the hash style, preferred debugging symbol
options and so on are expected to be used for all userspace binaries.

So somehow we do need to ensure that when the kernel is building
userspace binaries, it does use the options we expect and match the rest
of the system.

Equally, I do understand the kernel build system is a complex beast in
its own right.

We don't have to solve this instantly, but in general its considered a
bug if things like the hash-style in LDFLAGS don't make it to the linker
commandline. We do have QA tests that check for this, however they don't
function as they used to since we hard set the option on when we compile
the linker now :/.

Cheers,

Richard
Bruce Ashfield - Sept. 18, 2013, 4:14 p.m.
On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
>> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
>> <enrico.scholz@sigma-chemnitz.de> wrote:
>> > Otavio Salvador <otavio@ossystems.com.br> writes:
>> >
>> >> I don't agree on this. perf is tied to kernel and part of its code so
>> >> I think same exception rule apply for it as well.
>> >
>> > perf ships with the kernel but is a pure userspace program.  It does not
>> > require any special setup ('make configure'), it links against complex
>> > userspace gui frameworks and uses userspace headers.
>>
>> yes, we realize this .. we have a long a complicated history with perf and the
>> related build issues.
>>
>> We are stating our general policy, interfere with it's build as little
>> as possible.
>> Use extension variables, not clobber variables, etc.
>>
>> Otherwise, we end up creating our own issues, and have the bugs to prove it :)
>
> For the record, I do think Enrico does have a valid point here. We do
> put things in CFLAGS and LDFLAGS which we expect *all* userspace to be
> built with. Things like the hash style, preferred debugging symbol
> options and so on are expected to be used for all userspace binaries.
>
> So somehow we do need to ensure that when the kernel is building
> userspace binaries, it does use the options we expect and match the rest
> of the system.
>
> Equally, I do understand the kernel build system is a complex beast in
> its own right.
>
> We don't have to solve this instantly, but in general its considered a
> bug if things like the hash-style in LDFLAGS don't make it to the linker
> commandline. We do have QA tests that check for this, however they don't
> function as they used to since we hard set the option on when we compile
> the linker now :/.

Right, don't get me wrong in my comments. I'm just saying that I'd rather
add to the flags, versus completely clobber them. Since us imposing the
complete set of flags, is what has caused us the pain .. not adding to them.

Bruce


>
> Cheers,
>
> Richard
>
>
>
>
>
Richard Purdie - Sept. 18, 2013, 4:23 p.m.
On Wed, 2013-09-18 at 12:14 -0400, Bruce Ashfield wrote:
> On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
> >> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
> >> <enrico.scholz@sigma-chemnitz.de> wrote:
> >> > Otavio Salvador <otavio@ossystems.com.br> writes:
> >> >
> >> >> I don't agree on this. perf is tied to kernel and part of its code so
> >> >> I think same exception rule apply for it as well.
> >> >
> >> > perf ships with the kernel but is a pure userspace program.  It does not
> >> > require any special setup ('make configure'), it links against complex
> >> > userspace gui frameworks and uses userspace headers.
> >>
> >> yes, we realize this .. we have a long a complicated history with perf and the
> >> related build issues.
> >>
> >> We are stating our general policy, interfere with it's build as little
> >> as possible.
> >> Use extension variables, not clobber variables, etc.
> >>
> >> Otherwise, we end up creating our own issues, and have the bugs to prove it :)
> >
> > For the record, I do think Enrico does have a valid point here. We do
> > put things in CFLAGS and LDFLAGS which we expect *all* userspace to be
> > built with. Things like the hash style, preferred debugging symbol
> > options and so on are expected to be used for all userspace binaries.
> >
> > So somehow we do need to ensure that when the kernel is building
> > userspace binaries, it does use the options we expect and match the rest
> > of the system.
> >
> > Equally, I do understand the kernel build system is a complex beast in
> > its own right.
> >
> > We don't have to solve this instantly, but in general its considered a
> > bug if things like the hash-style in LDFLAGS don't make it to the linker
> > commandline. We do have QA tests that check for this, however they don't
> > function as they used to since we hard set the option on when we compile
> > the linker now :/.
> 
> Right, don't get me wrong in my comments. I'm just saying that I'd rather
> add to the flags, versus completely clobber them. Since us imposing the
> complete set of flags, is what has caused us the pain .. not adding to them.

Isn't that what the patch at the start of this thread is doing though
(clobbering, not adding)?  :/

I really need to figure out whether to take this patch or not and it
looks like there isn't an easy answer...

Cheers,

Richard
Bruce Ashfield - Sept. 18, 2013, 4:27 p.m.
On Wed, Sep 18, 2013 at 12:23 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2013-09-18 at 12:14 -0400, Bruce Ashfield wrote:
>> On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> > On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
>> >> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
>> >> <enrico.scholz@sigma-chemnitz.de> wrote:
>> >> > Otavio Salvador <otavio@ossystems.com.br> writes:
>> >> >
>> >> >> I don't agree on this. perf is tied to kernel and part of its code so
>> >> >> I think same exception rule apply for it as well.
>> >> >
>> >> > perf ships with the kernel but is a pure userspace program.  It does not
>> >> > require any special setup ('make configure'), it links against complex
>> >> > userspace gui frameworks and uses userspace headers.
>> >>
>> >> yes, we realize this .. we have a long a complicated history with perf and the
>> >> related build issues.
>> >>
>> >> We are stating our general policy, interfere with it's build as little
>> >> as possible.
>> >> Use extension variables, not clobber variables, etc.
>> >>
>> >> Otherwise, we end up creating our own issues, and have the bugs to prove it :)
>> >
>> > For the record, I do think Enrico does have a valid point here. We do
>> > put things in CFLAGS and LDFLAGS which we expect *all* userspace to be
>> > built with. Things like the hash style, preferred debugging symbol
>> > options and so on are expected to be used for all userspace binaries.
>> >
>> > So somehow we do need to ensure that when the kernel is building
>> > userspace binaries, it does use the options we expect and match the rest
>> > of the system.
>> >
>> > Equally, I do understand the kernel build system is a complex beast in
>> > its own right.
>> >
>> > We don't have to solve this instantly, but in general its considered a
>> > bug if things like the hash-style in LDFLAGS don't make it to the linker
>> > commandline. We do have QA tests that check for this, however they don't
>> > function as they used to since we hard set the option on when we compile
>> > the linker now :/.
>>
>> Right, don't get me wrong in my comments. I'm just saying that I'd rather
>> add to the flags, versus completely clobber them. Since us imposing the
>> complete set of flags, is what has caused us the pain .. not adding to them.
>
> Isn't that what the patch at the start of this thread is doing though
> (clobbering, not adding)?  :/

It definitely is, and I had put in the bugzilla that it is a compromise for now,
since perf only offers EXTRA_CFLAGS and not EXTRA_LDFLAGS. I'll see
about addressing that upstream once we get out of this fix :)

Bruce

>
> I really need to figure out whether to take this patch or not and it
> looks like there isn't an easy answer...
>
> Cheers,
>
> Richard
>
Otavio Salvador - Sept. 18, 2013, 4:34 p.m.
On Wed, Sep 18, 2013 at 1:27 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 12:23 PM, Richard Purdie
...
>> Isn't that what the patch at the start of this thread is doing though
>> (clobbering, not adding)?  :/
>
> It definitely is, and I had put in the bugzilla that it is a compromise for now,
> since perf only offers EXTRA_CFLAGS and not EXTRA_LDFLAGS. I'll see
> about addressing that upstream once we get out of this fix :)

For now, this seems to address all urgent issues; so please pick this one.

Patch

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 4a815ff..269069f 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -60,6 +60,11 @@  B = "${WORKDIR}/${BPN}-${PV}"
 SCRIPTING_DEFINES = "${@perf_feature_enabled('perf-scripting', '', 'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
 TUI_DEFINES = "${@perf_feature_enabled('perf-tui', '', 'NO_NEWT=1',d)}"
 
+# The LDFLAGS is required or some old kernels fails due missing
+# symbols and this is preferred than requiring patches to every old
+# supported kernel.
+LDFLAGS="-ldl -lutil"
+
 EXTRA_OEMAKE = \
 		'-C ${S}/tools/perf \
 		O=${B} \
@@ -88,13 +93,13 @@  PARALLEL_MAKE = ""
 
 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