[PATCH 0/2] ppc/native: Fix native builds with PowerPC 32-bit host system

[PATCH 0/2] ppc/native: Fix native builds with PowerPC 32-bit host system

[Serhey Popovych]

In some specific environments on PowerPC native builds failing due to:

  a) libgpg-error requires TARGET_ARCH tuple mapping to supported tuple
  b) binutils fails to build with --enable-targets=all due to small bss
     and data relocation failures.

To fix a) is trivial: we need to add tuple mapping for TARGET_ARCH=ppc.

Fixing b) isn't simple because with --enable-targets=all binary becomes
too big to support R_PPC_GOT16 relocations against small bss/data. Since
for native builds we only need libbfd, libiberty and libopcodes we can
build only these three archives and their dependencies.

See individual commit message for details on each change presented.

Serhey Popovych (2):
  libgpg-error: Support build for native on ppc host
  binutils: Speed up and fix native builds

 meta/recipes-devtools/binutils/binutils_2.31.bb    | 33 +++++++++++++---------
 .../libgpg-error/libgpg-error_1.33.bb              |  1 +
 2 files changed, 20 insertions(+), 14 deletions(-)

-- 
2.7.4

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

[Serhey Popovych]

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@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 ;;
-- 
2.7.4

[PATCH 2/2] binutils: Speed up and fix native builds

[Serhey Popovych]

We need only libbfd, libiberty and libopcodes from binutils native.
To get them we build entire binutils with --enable-targets=all to
include all possible output targets support and then remove all but
these three libs.

This has two side effects:

  1) it wastes build time
  2) may cause errors caused by --enable-targets=all on some exotics
     build hosts like PowerPC 32bit

To address both of these effects we can configure binutils in general
and only required libs and their dependencies (zlib and intl at the
time). Then build only build these libs and their dependencies.

Regarding to PowerPC 32-bit build host issues we get following errors
when building on Ubuntu 16.04 LTS for PowerPC with command:

  MACHINE=qemuppc setarch ppc bitbake binutils-native

<output omitted>
| /usr/lib/gcc/powerpc-linux-gnu/5/../../../powerpc-linux-gnu/crti.o: In function `_init':
| (.init+0x22): relocation truncated to fit: R_PPC_GOT16 against undefined symbol `__gmon_start__'
| dwarf.o: In function `parse_gnu_debuglink':
| dwarf.c:(.text+0x482): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.o: In function `fetch_indexed_string':
| dwarf.c:(.text+0x8fa): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.o: In function `read_debug_line_header':
| dwarf.c:(.text+0x114a): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.c:(.text+0x12c6): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.o: In function `display_debug_ranges_list':
| dwarf.c:(.text+0x187e): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.c:(.text+0x18a2): relocation truncated to fit: R_PPC_GOT16 against symbol `stdout@@GLIBC_2.0' defined in .sdata section in /lib/powerpc-linux-gnu/libc.so.6
| dwarf.o: In function `display_debug_rnglists_list':
| dwarf.c:(.text+0x1bf2): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.c:(.text+0x1c06): relocation truncated to fit: R_PPC_GOT16 against symbol `stdout@@GLIBC_2.0' defined in .sdata section in /lib/powerpc-linux-gnu/libc.so.6
| dwarf.o: In function `display_block':
| dwarf.c:(.text+0x2486): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
| dwarf.o: In function `introduce.isra.2':
| dwarf.c:(.text+0x2556): additional relocation overflows omitted from the output
| collect2: error: ld returned 1 exit status
| Makefile:909: recipe for target 'objdump' failed
| make[4]: *** [objdump] Error 1
| make[4]: *** Waiting for unfinished jobs....
<output omitted>

While 'byte_get' is defined in small bss section in elfcomm.o and
generally can be fixed, symbol from host glibc 'stdout@@GLIBC_2.0' in
small data section can't be moved without recompile of Ubuntu 16.04 LTS
glibc.

Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
 meta/recipes-devtools/binutils/binutils_2.31.bb | 33 ++++++++++++++-----------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils_2.31.bb b/meta/recipes-devtools/binutils/binutils_2.31.bb
index 51a9748..6796749 100644
--- a/meta/recipes-devtools/binutils/binutils_2.31.bb
+++ b/meta/recipes-devtools/binutils/binutils_2.31.bb
@@ -20,26 +20,31 @@ EXTRA_OECONF_class-native = "--enable-targets=all \
                              --enable-install-libbfd \
                              --disable-werror"
 
+do_configure_append_class-native () {
+	for l in zlib intl bfd libiberty opcodes; do
+		oe_runmake configure-${l}
+	done
+}
+
+do_compile_class-native () {
+	for l in zlib intl bfd libiberty opcodes; do
+		cd "${l}"
+		autotools_do_compile
+		cd - >/dev/null
+	done
+}
+
 do_install_class-native () {
-	autotools_do_install
+	for l in bfd libiberty opcodes; do
+		cd "${l}"
+		autotools_do_install
+		cd - >/dev/null
+	done
 
 	# Install the libiberty header
 	install -d ${D}${includedir}
 	install -m 644 ${S}/include/ansidecl.h ${D}${includedir}
 	install -m 644 ${S}/include/libiberty.h ${D}${includedir}
-
-	# We only want libiberty, libbfd and libopcodes
-	rm -rf ${D}${bindir}
-	rm -rf ${D}${prefix}/${TARGET_SYS}
-	rm -rf ${D}${prefix}/lib/ldscripts
-	rm -rf ${D}${prefix}/share/info
-	rm -rf ${D}${prefix}/share/locale
-	rm -rf ${D}${prefix}/share/man
-	rmdir ${D}${prefix}/share || :
-	rmdir ${D}/${libdir}/gcc-lib || :
-	rmdir ${D}/${libdir}64/gcc-lib || :
-	rmdir ${D}/${libdir} || :
-	rmdir ${D}/${libdir}64 || :
 }
 
 # Split out libbfd-*.so so including perf doesn't include extra stuff
-- 
2.7.4

Re: [PATCH 2/2] binutils: Speed up and fix native builds

[Khem Raj]

On Sat, Jan 12, 2019 at 2:12 AM Serhey Popovych
<serhe.popovych@gmail.com> wrote:
>
> We need only libbfd, libiberty and libopcodes from binutils native.
> To get them we build entire binutils with --enable-targets=all to
> include all possible output targets support and then remove all but
> these three libs.
>
> This has two side effects:
>
>   1) it wastes build time
>   2) may cause errors caused by --enable-targets=all on some exotics
>      build hosts like PowerPC 32bit
>
> To address both of these effects we can configure binutils in general
> and only required libs and their dependencies (zlib and intl at the
> time). Then build only build these libs and their dependencies.
>
> Regarding to PowerPC 32-bit build host issues we get following errors
> when building on Ubuntu 16.04 LTS for PowerPC with command:
>
>   MACHINE=qemuppc setarch ppc bitbake binutils-native
>
> <output omitted>
> | /usr/lib/gcc/powerpc-linux-gnu/5/../../../powerpc-linux-gnu/crti.o: In function `_init':
> | (.init+0x22): relocation truncated to fit: R_PPC_GOT16 against undefined symbol `__gmon_start__'
> | dwarf.o: In function `parse_gnu_debuglink':
> | dwarf.c:(.text+0x482): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.o: In function `fetch_indexed_string':
> | dwarf.c:(.text+0x8fa): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.o: In function `read_debug_line_header':
> | dwarf.c:(.text+0x114a): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.c:(.text+0x12c6): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.o: In function `display_debug_ranges_list':
> | dwarf.c:(.text+0x187e): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.c:(.text+0x18a2): relocation truncated to fit: R_PPC_GOT16 against symbol `stdout@@GLIBC_2.0' defined in .sdata section in /lib/powerpc-linux-gnu/libc.so.6
> | dwarf.o: In function `display_debug_rnglists_list':
> | dwarf.c:(.text+0x1bf2): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.c:(.text+0x1c06): relocation truncated to fit: R_PPC_GOT16 against symbol `stdout@@GLIBC_2.0' defined in .sdata section in /lib/powerpc-linux-gnu/libc.so.6
> | dwarf.o: In function `display_block':
> | dwarf.c:(.text+0x2486): relocation truncated to fit: R_PPC_GOT16 against symbol `byte_get' defined in .sbss section in elfcomm.o
> | dwarf.o: In function `introduce.isra.2':
> | dwarf.c:(.text+0x2556): additional relocation overflows omitted from the output
> | collect2: error: ld returned 1 exit status
> | Makefile:909: recipe for target 'objdump' failed
> | make[4]: *** [objdump] Error 1
> | make[4]: *** Waiting for unfinished jobs....
> <output omitted>
>
> While 'byte_get' is defined in small bss section in elfcomm.o and
> generally can be fixed, symbol from host glibc 'stdout@@GLIBC_2.0' in
> small data section can't be moved without recompile of Ubuntu 16.04 LTS
> glibc.
>

Can you try to add -fPIC to CFLAGS ? this should help in fixing the
relocation spill.


> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
> ---
>  meta/recipes-devtools/binutils/binutils_2.31.bb | 33 ++++++++++++++-----------
>  1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/meta/recipes-devtools/binutils/binutils_2.31.bb b/meta/recipes-devtools/binutils/binutils_2.31.bb
> index 51a9748..6796749 100644
> --- a/meta/recipes-devtools/binutils/binutils_2.31.bb
> +++ b/meta/recipes-devtools/binutils/binutils_2.31.bb
> @@ -20,26 +20,31 @@ EXTRA_OECONF_class-native = "--enable-targets=all \
>                               --enable-install-libbfd \
>                               --disable-werror"
>
> +do_configure_append_class-native () {
> +       for l in zlib intl bfd libiberty opcodes; do
> +               oe_runmake configure-${l}
> +       done
> +}

lets use --disable-<DIR> instead in EXTRA_OECONF

> +
> +do_compile_class-native () {
> +       for l in zlib intl bfd libiberty opcodes; do
> +               cd "${l}"
> +               autotools_do_compile
> +               cd - >/dev/null
> +       done
> +}
> +

not needed

>  do_install_class-native () {
> -       autotools_do_install
> +       for l in bfd libiberty opcodes; do
> +               cd "${l}"
> +               autotools_do_install
> +               cd - >/dev/null
> +       done
>

not needed


>         # Install the libiberty header
>         install -d ${D}${includedir}
>         install -m 644 ${S}/include/ansidecl.h ${D}${includedir}
>         install -m 644 ${S}/include/libiberty.h ${D}${includedir}
> -
> -       # We only want libiberty, libbfd and libopcodes
> -       rm -rf ${D}${bindir}
> -       rm -rf ${D}${prefix}/${TARGET_SYS}
> -       rm -rf ${D}${prefix}/lib/ldscripts
> -       rm -rf ${D}${prefix}/share/info
> -       rm -rf ${D}${prefix}/share/locale
> -       rm -rf ${D}${prefix}/share/man
> -       rmdir ${D}${prefix}/share || :
> -       rmdir ${D}/${libdir}/gcc-lib || :
> -       rmdir ${D}/${libdir}64/gcc-lib || :
> -       rmdir ${D}/${libdir} || :
> -       rmdir ${D}/${libdir}64 || :
>  }
>
>  # Split out libbfd-*.so so including perf doesn't include extra stuff
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

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

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

[Serhey Popovych]

[-- Attachment #1.1: Type: text/plain, Size: 2522 bytes --]

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@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).

> 
> Cheers,
> 
> Richard
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

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

[Richard Purdie]

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

Cheers,

Richard

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

[Serhey Popovych]

[-- Attachment #1.1: Type: text/plain, Size: 3122 bytes --]

Richard Purdie 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@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?

Problem only when PowerPC 32-bit (running in VM for example) is used as
build host.

For that "uname -m" returns ppc, that mapping is missing for
libgpg-error tuple.

> 
> Cheers,
> 
> Richard
> 
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

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

[Khem Raj]

On Sat, Jan 12, 2019 at 8:22 AM Richard Purdie
<richard.purdie@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@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 :)

>
> Cheers,
>
> Richard
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

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

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

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

[Serhey Popovych]

[-- Attachment #1.1: Type: text/plain, Size: 4285 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [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@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@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@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
>
>
>