[OE-core] [OE-Core][PATCH 1/2] libgpg-error: Support build for native on ppc host

Serhey Popovych serhe.popovych at gmail.com
Sat Jan 12 19:51:37 UTC 2019


Richard Purdie wrote:
> On Sat, 2019-01-12 at 10:31 -0800, Khem Raj wrote:
>> On Sat, Jan 12, 2019 at 8:22 AM Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>>> On Sat, 2019-01-12 at 17:56 +0200, Serhey Popovych wrote:
>>>> Richard Purdie wrote:
>>>>> On Sat, 2019-01-12 at 12:11 +0200, Serhey Popovych wrote:
>>>>>> In Ubuntu 16.04 LTS userspace is build for PowerPC 32-bit
>>>>>> while
>>>>>> kernel
>>>>>> selected by the installer depending on PowerPC machine type:
>>>>>>
>>>>>>   * 32-bit for PowerMac G4 (ppc7400) and below
>>>>>>   * 64-bit for PowerMac G5 and above
>>>>>>
>>>>>> Thus uname(2) returns ppc64 for 64-bit kernels and 32-bit
>>>>>> userspace
>>>>>> making build impossible due to missing some of lib64 multilib
>>>>>> equivalents in Ubuntu repository.
>>>>>>
>>>>>> Using setarch(8) override to make whole host look as PowerPC
>>>>>> 32-
>>>>>> bit
>>>>>> can actually help with build but requires mapping for ppc
>>>>>> target
>>>>>> to
>>>>>> their libgpg-error equivalent to fix native build.
>>>>>>
>>>>>> Build tested on Ubuntu 16.04 LTS host on PowerMac G5 with
>>>>>> command:
>>>>>>
>>>>>>   MACHINE=qemuppc setarch ppc bitbake core-image-full-cmdline
>>>>>>
>>>>>> Signed-off-by: Serhey Popovych <serhe.popovych at gmail.com>
>>>>>> ---
>>>>>>  meta/recipes-support/libgpg-error/libgpg-error_1.33.bb | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/meta/recipes-support/libgpg-error/libgpg-
>>>>>> error_1.33.bb
>>>>>> b/meta/recipes-support/libgpg-error/libgpg-error_1.33.bb
>>>>>> index 325529d..4153954 100644
>>>>>> --- a/meta/recipes-support/libgpg-error/libgpg-error_1.33.bb
>>>>>> +++ b/meta/recipes-support/libgpg-error/libgpg-error_1.33.bb
>>>>>> @@ -47,6 +47,7 @@ do_compile_prepend() {
>>>>>>     mips*el)    TUPLE=mipsel-unknown-linux-gnu ;;
>>>>>>     mips*)      TUPLE=mips-unknown-linux-gnu ;;
>>>>>>     x86_64)     TUPLE=x86_64-unknown-linux-gnu ;;
>>>>>> +   ppc)        TUPLE=powerpc-unknown-linux-gnu ;;
>>>>>>     ppc64)      TUPLE=powerpc64-unknown-linux-gnu ;;
>>>>>>     ppc64le)    TUPLE=powerpc64le-unknown-linux-gnu ;;
>>>>>>     *)          TUPLE=${TARGET_ARCH}-unknown-linux-gnu ;;
>>>>>
>>>>> This doesn't feel correct. It only works if you're using the
>>>>> local
>>>>> setarch workaround and I'm worried most users are never going
>>>>> to
>>>>> find
>>>>> that.
>>>>>
>>>>> I'm fine with adding in general fixes but this is getting very
>>>>> specific
>>>>> to an very uncommon usecase :(
>>>>
>>>> Understand your position. Doing setarch(8) to run bitbake on
>>>> ppc64
>>>> kernel with 32-bit user space with missing 64-bit multilib seems
>>>> to
>>>> be the only option.
>>>>
>>>> Anyway this change just maps ppc to corresponding tuple used by
>>>> libgpg-error, so with this fix we hit both
>>>>
>>>>   a) setarch(1) when kernel is 64-bit and userspace is 32-bit and
>>>>      no multilib
>>>>   b) native 32-bit powerpc host that is running as virtual
>>>> machine
>>>> for
>>>>      example).
>>>
>>> I'd understand that if this were just libgpg-error-native but our
>>> qemuppc builds work which I guess is why I don't quite understand
>>> what
>>> is wrong here?
>>
>> this is when using ppc32 as build host :)
> 
> I appreciate that. My point is that we can build for ppc32 target
> machines (qemuppc) so why are ppc32 target machines using a different
> arch to native ppc32 machines?

For target we have TUNE_ARCH, for native we have BUILD_ARCH that comes
from uname(2).

So for target we hit *) in case statement, while for native we hit
special cases from various uname(2) (and where ppc is missing for
ppc32).

> 
> If the native and target recipes were different I could understand it
> but they're not.


> 
> Could is mean we're using a non-standard name for ppc32 target builds?
> or does it mean setarch should be to something else like powerpc on
> native builds? Basically I worry that we're using different names for
> the same thing.

In sense of uname(2) and TUNE_ARCH mismatch this looks as true.

However for configure triplet for target powerpc, powerpc64 and
powerpc64le are used nearly always.

> 
> Cheers,
> 
> Richard
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190112/baa85686/attachment-0001.sig>


More information about the Openembedded-core mailing list