[3/4] devtools: add ppc64 in meson build test
Checks
Commit Message
The CPU is defined as Power8, running as little endian.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
config/ppc/ppc64le-power8-linux-gcc | 11 +++++++++++
devtools/test-meson-builds.sh | 5 +++++
2 files changed, 16 insertions(+)
create mode 100644 config/ppc/ppc64le-power8-linux-gcc
Comments
On 6/14/20 3:57 PM, Thomas Monjalon wrote:
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 1d80a029aa..1cde17a2e5 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -212,6 +212,11 @@ for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
> unset CC
> done
>
> +# ppc configurations
> +for f in $srcdir/config/ppc/ppc* ; do
> + build build-$(basename $f | cut -d'-' -f-2) $f $use_shared
> +done
> +
The entire script file is poorly structured for multi-architecture
builds. The script fails on PPC64LE even before your changes:
------------------------------------
# shared and static linked builds with gcc and clang
for c in gcc clang ; do
command -v $c >/dev/null 2>&1 || continue
for s in static shared ; do
export CC="$CCACHE $c"
build build-$c-$s $c --default-library=$s
unset CC
done
done
------------------------------------
Compilation on clang is not currently supported due to build failures on
Altivec data types for vectorization:
In file included from ../lib/librte_eal/common/eal_common_options.c:33:
In file included from ../lib/librte_eal/ppc/include/rte_memcpy.h:12:
In file included from ../lib/librte_eal/ppc/include/rte_altivec.h:10:
/usr/lib64/clang/9.0.1/include/altivec.h:55:19: error: unknown type name
'vector'
static __inline__ vector bool char __ATTRS_o_ai
^
/usr/lib64/clang/9.0.1/include/altivec.h:56:10: error: unknown type name
'vector'
vec_perm(vector bool char __a, vector bool char __b, vector unsigned
char __c);
and C99 atomics:
../lib/librte_eal/ppc/include/rte_atomic.h:85:9: error: implicit
declaration of function '__atomic_exchange_2' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
return __atomic_exchange_2(dst, val, __ATOMIC_SEQ_CST);
^
The script then immediately launches into an x86 build no matter what
architecture the system is running on:
------------------------------------
default_machine='nehalem'
ok=$(cc -march=$default_machine -E - < /dev/null > /dev/null 2>&1 ||
echo false)
if [ "$ok" = "false" ] ; then
default_machine='corei7'
fi
build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine
$use_shared
------------------------------------
Which also fails on a Power system:
ninja -v -C ./build-x86-default
ninja: Entering directory `./build-x86-default'
[1/2265] cc -Ilib/76b5a35@@rte_kvargs@sta -Ilib -I../lib -I. -I../
-Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/ppc/include
-I../lib/librte_eal/ppc/include -Ilib/librte_kvargs
-I../lib/librte_kvargs -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g -include
rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat-nonliteral
-Wformat-security -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -mcpu=corei7
-mtune=corei7 -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -MD -MQ
'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o' -MF
'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o.d' -o
'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o' -c
../lib/librte_kvargs/rte_kvargs.c
FAILED: lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o
I think the logic of looping through supported configs for test builds
is the right one, but more changes are required for multi-architecture
support in this script. For now I'd abandon the PPC/ARM support
entirely in this script.
Dave
15/06/2020 23:43, David Christensen:
> On 6/14/20 3:57 PM, Thomas Monjalon wrote:
> > diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> > index 1d80a029aa..1cde17a2e5 100755
> > --- a/devtools/test-meson-builds.sh
> > +++ b/devtools/test-meson-builds.sh
> > @@ -212,6 +212,11 @@ for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
> > unset CC
> > done
> >
> > +# ppc configurations
> > +for f in $srcdir/config/ppc/ppc* ; do
> > + build build-$(basename $f | cut -d'-' -f-2) $f $use_shared
> > +done
> > +
>
> The entire script file is poorly structured for multi-architecture
> builds. The script fails on PPC64LE even before your changes:
This script supports only builds from x86 Linux so far.
This patch is adding cross-compilation of ppc from x86,
and it works fine.
> ------------------------------------
> # shared and static linked builds with gcc and clang
> for c in gcc clang ; do
> command -v $c >/dev/null 2>&1 || continue
> for s in static shared ; do
> export CC="$CCACHE $c"
> build build-$c-$s $c --default-library=$s
> unset CC
> done
> done
> ------------------------------------
>
> Compilation on clang is not currently supported due to build failures on
> Altivec data types for vectorization:
>
> In file included from ../lib/librte_eal/common/eal_common_options.c:33:
> In file included from ../lib/librte_eal/ppc/include/rte_memcpy.h:12:
> In file included from ../lib/librte_eal/ppc/include/rte_altivec.h:10:
> /usr/lib64/clang/9.0.1/include/altivec.h:55:19: error: unknown type name
> 'vector'
> static __inline__ vector bool char __ATTRS_o_ai
> ^
> /usr/lib64/clang/9.0.1/include/altivec.h:56:10: error: unknown type name
> 'vector'
> vec_perm(vector bool char __a, vector bool char __b, vector unsigned
> char __c);
>
> and C99 atomics:
>
> ../lib/librte_eal/ppc/include/rte_atomic.h:85:9: error: implicit
> declaration of function '__atomic_exchange_2' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
> return __atomic_exchange_2(dst, val, __ATOMIC_SEQ_CST);
> ^
>
> The script then immediately launches into an x86 build no matter what
> architecture the system is running on:
>
> ------------------------------------
> default_machine='nehalem'
> ok=$(cc -march=$default_machine -E - < /dev/null > /dev/null 2>&1 ||
> echo false)
> if [ "$ok" = "false" ] ; then
> default_machine='corei7'
> fi
> build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine
> $use_shared
> ------------------------------------
>
> Which also fails on a Power system:
>
> ninja -v -C ./build-x86-default
> ninja: Entering directory `./build-x86-default'
> [1/2265] cc -Ilib/76b5a35@@rte_kvargs@sta -Ilib -I../lib -I. -I../
> -Iconfig -I../config -Ilib/librte_eal/include
> -I../lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../lib/librte_eal/linux/include -Ilib/librte_eal/ppc/include
> -I../lib/librte_eal/ppc/include -Ilib/librte_kvargs
> -I../lib/librte_kvargs -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g -include
> rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat-nonliteral
> -Wformat-security -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -mcpu=corei7
> -mtune=corei7 -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
> -Wno-format-truncation -MD -MQ
> 'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o' -MF
> 'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o.d' -o
> 'lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o' -c
> ../lib/librte_kvargs/rte_kvargs.c
> FAILED: lib/76b5a35@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o
>
>
> I think the logic of looping through supported configs for test builds
> is the right one, but more changes are required for multi-architecture
> support in this script. For now I'd abandon the PPC/ARM support
> entirely in this script.
I am adding PPC compilation check to avoid having PPC broken,
because after asking for many years to IBM execs,
there is still no PPC CI integrated in DPDK patchwork.
If you don't think this small step is going in the right direction,
then I will stop bothering about PPC support,
and we should probably completely drop PPC support I guess.
>>> +# ppc configurations
>>> +for f in $srcdir/config/ppc/ppc* ; do
>>> + build build-$(basename $f | cut -d'-' -f-2) $f $use_shared
>>> +done
>>> +
>>
>> The entire script file is poorly structured for multi-architecture
>> builds. The script fails on PPC64LE even before your changes:
>
> This script supports only builds from x86 Linux so far.
> This patch is adding cross-compilation of ppc from x86,
> and it works fine.
Which distro and packages are used for testing? I tried it with Ubuntu
20.04 but the cross-compiler is named differently
(powerpc64le-linux-gnu-gcc instead of powerpc64le-linux-gcc).
>> I think the logic of looping through supported configs for test builds
>> is the right one, but more changes are required for multi-architecture
>> support in this script. For now I'd abandon the PPC/ARM support
>> entirely in this script.
>
> I am adding PPC compilation check to avoid having PPC broken,
> because after asking for many years to IBM execs,
> there is still no PPC CI integrated in DPDK patchwork.
> If you don't think this small step is going in the right direction,
> then I will stop bothering about PPC support,
> and we should probably completely drop PPC support I guess.
Sorry, I didn't understand the context behind the change request nor how
the script is used. I appreciate the effort behind the change and would
like to help where I can.
Dave
16/06/2020 22:35, David Christensen:
> Thomas Monjalon wrote:
> > This script supports only builds from x86 Linux so far.
> > This patch is adding cross-compilation of ppc from x86,
> > and it works fine.
>
> Which distro and packages are used for testing? I tried it with Ubuntu
> 20.04 but the cross-compiler is named differently
> (powerpc64le-linux-gnu-gcc instead of powerpc64le-linux-gcc).
I'm using a buildroot toolchain from bootlin:
https://toolchains.bootlin.com/releases_powerpc64le-power8.html
If it is more common to have "gnu" in the prefix,
no problem to change it in this patch.
I can create "gnu" symbolic links in my toolchain.
Ideally I would like to have an option to specify the toolchain prefix
with meson, instead of hardcoding it in a cross file.
> 16/06/2020 22:35, David Christensen:
>> Thomas Monjalon wrote:
>>> This script supports only builds from x86 Linux so far.
>>> This patch is adding cross-compilation of ppc from x86,
>>> and it works fine.
>>
>> Which distro and packages are used for testing? I tried it with Ubuntu
>> 20.04 but the cross-compiler is named differently
>> (powerpc64le-linux-gnu-gcc instead of powerpc64le-linux-gcc).
>
> I'm using a buildroot toolchain from bootlin:
> https://toolchains.bootlin.com/releases_powerpc64le-power8.html
>
> If it is more common to have "gnu" in the prefix,
> no problem to change it in this patch.
> I can create "gnu" symbolic links in my toolchain.
>
> Ideally I would like to have an option to specify the toolchain prefix
> with meson, instead of hardcoding it in a cross file.
If there's no defined distro where this tool is expected to be used I'd
be happy with a comment in the cross file indicating which set of
cross-compilers you chose for the implementation.
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
new file mode 100644
@@ -0,0 +1,11 @@
+[binaries]
+c = 'powerpc64le-linux-gcc'
+cpp = 'powerpc64le-linux-cpp'
+ar = 'powerpc64le-linux-gcc-ar'
+strip = 'powerpc64le-linux-strip'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'ppc64'
+cpu = 'power8'
+endian = 'little'
@@ -212,6 +212,11 @@ for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
unset CC
done
+# ppc configurations
+for f in $srcdir/config/ppc/ppc* ; do
+ build build-$(basename $f | cut -d'-' -f-2) $f $use_shared
+done
+
# Test installation of the x86-default target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
build_path=$(readlink -f $builds_dir/build-x86-default)