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

Richard Purdie richard.purdie at linuxfoundation.org
Sat Jan 12 15:40:12 UTC 2019


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 :(

Cheers,

Richard



More information about the Openembedded-core mailing list