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

[Khem Raj]

On Sat, Jan 12, 2019 at 11:18 AM Richard Purdie
<richard.purdie at linuxfoundation.org> 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?

Thats because for our ppc32 targets TARGET_ARCH is 'powerpc' and not ppc
which has one to one mapping for target specific lock-obj-pub.h file

>
> 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?

Not really.

> or does it mean setarch should be to something else like powerpc on
> native builds?

yes historically ppc is ok they are used interchangeably

Basically I worry that we're using different names for
> the same thing.
>
> Cheers,
>
> Richard
>
>
>