[OE-core] [PATCH 07/16] Fix lttng-ust for powerpc64

[Saul Wold]

On 09/29/2011 11:46 AM, Richard Purdie wrote:
> On Thu, 2011-09-29 at 18:21 +0000, McClintock Matthew-B29882 wrote:
>> On Thu, Sep 29, 2011 at 10:50 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org>  wrote:
>>> On Wed, 2011-09-28 at 23:21 -0500, Matthew McClintock wrote:
>>>> Signed-off-by: Matthew McClintock<msm at freescale.com>
>>>> ---
>>>>   meta/recipes-kernel/lttng/fix-powerpc64.patch |   17 +++++++++++++++++
>>>>   meta/recipes-kernel/lttng/lttng-ust_0.15.bb   |    3 ++-
>>>>   2 files changed, 19 insertions(+), 1 deletions(-)
>>>>   create mode 100644 meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>>
>>>> diff --git a/meta/recipes-kernel/lttng/fix-powerpc64.patch b/meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>> new file mode 100644
>>>> index 0000000..d347979
>>>> --- /dev/null
>>>> +++ b/meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>> @@ -0,0 +1,17 @@
>>>> +Upstream-Status: Inappropriate configuration
>>>
>>> Is this really inappropriate for upstream? It looks reasonable to me...
>>
>> Seems reasonable. What is the policy on this? Can I mark it "this
>> should be upstreamed" or must I mark it "this was sent upstream" and
>> then upstream the change?
>
> There is some marking for "should be upstreamed"/upstreamable.
>
The marking would be "Pending", this indicates that it should be 
attempted, if it gets up streamed then marked Accepted with a pointer to 
the potential upstream version or ref.

Thanks
	Sau!

>>>> +Add bit to detect if we are running on powerpc64 and treat it the
>>>> +same as ppc64
>>>> +
>>>> +Index: ust-0.15/configure.ac
>>>> +===================================================================
>>>> +--- ust-0.15.orig/configure.ac
>>>> ++++ ust-0.15/configure.ac
>>>> +@@ -111,6 +111,7 @@ changequote([,])dnl
>>>> +     x86_64) LIBFORMAT="elf64-x86-64" ;;
>>>> +     powerpc) LIBFORMAT="elf32-powerpc" ;;
>>>> +     ppc64) LIBFORMAT="elf64-powerpc" ;;
>>>> ++    powerpc64) LIBFORMAT="elf64-powerpc" ;;
>>>> +     s390) LIBFORMAT="elf32-s390" ;;
>>>> +     s390x) LIBFORMAT="elf64-s390" ;;
>>>> +         armv5) LIBFORMAT="elf32-littlearm"; NO_UNALIGNED_ACCESS=1 ;;
>>>> diff --git a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> index 915e619..9dd4658 100644
>>>> --- a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> +++ b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> @@ -10,9 +10,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \
>>>>
>>>>   DEPENDS = "liburcu"
>>>>
>>>> -PR = "r2"
>>>> +PR = "r3"
>>>>
>>>>   SRC_URI = "http://lttng.org/files/ust/releases/ust-${PV}.tar.gz"
>>>> +SRC_URI_append_powerpc64 = " file://fix-powerpc64.patch"
>>>
>>> Does this really need to be conditional on powerppc64? Looks like it can
>>> be applied unconditionally...
>>
>> True, was trying to minimally effect other stuff. But I take it by the
>> comment you prefer this be done away with.
>
> Sometimes minimally affecting other code is good. In this its obviously
> not going to break anything else so it can be universal. The risk of
> minimal application is fewer people testing it, e.g. when versions get
> upgraded.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>