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? 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. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
