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 >> <[email protected]> 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 <[email protected]> >>>>>> --- >>>>>> 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 > > >
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
