Add support for cross-compiling for ppc64le platform

[sumitd2]

..on the lines of #6441

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: sumitd2 (9cc1914)

[ejona86]

Looks like we need to check what distro and stuff is being used in kokoro. :-/

+ sudo apt-get install -y g++-10-powerpc64-linux-gnu
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package g++-10-powerpc64-linux-gnu
E: Couldn't find any package by regex 'g++-10-powerpc64-linux-gnu'

[sumitd2]

Not sure how to fix this for cross compilation:

> Task :grpc-compiler:linkJava_pluginExecutable FAILED
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: skipping incompatible /tmp/protobuf/lib/libprotoc.a when searching for -lprotoc
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: skipping incompatible //usr/local/lib/libprotoc.a when searching for -lprotoc
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: cannot find -lprotoc
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: skipping incompatible /tmp/protobuf/lib/libprotobuf.a when searching for -lprotobuf
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: skipping incompatible //usr/local/lib/libprotobuf.a when searching for -lprotobuf
/usr/lib/gcc-cross/powerpc64-linux-gnu/5/../../../../powerpc64-linux-gnu/bin/ld: cannot find -lprotobuf
collect2: error: ld returned 1 exit status

[ejona86]

Those incompatible libraries are most likely x86 libraries. The incompatible libraries aren't much of a problem; they will be skipped. The real problem is cannot find -lprotoc, which means the ppc libraries were not available. If you look at the end of make_dependencies.sh, you'll see:

export LDFLAGS=-L/tmp/protobuf/lib
export CXXFLAGS=-I/tmp/protobuf/include
export LD_LIBRARY_PATH=/tmp/protobuf/lib

-L in LDFLAGS adds a path to be searched when linking (the step you are seeing an error). And LD_LIBRARY_PATH adds a path to be searched when running the binary.

[sumitd2]

The host string looks wrong to me. Adding the fix...

+ ./configure --disable-shared --host=ppc64le-linux-gnu --prefix=/tmp/protobuf-cache/3.19.2/Linux-ppcle_64
checking host system type... powerpc64le-unknown-linux-gnu
checking target system type... powerpc64le-unknown-linux-gnu
checking for ppc64le-linux-gnu-gcc... no
checking for gcc... gcc
**checking whether we are cross compiling... no**
checking for ppc64le-linux-gnu-g++... no
checking for g++... g++

+ ./configure --disable-shared --host=aarch64-linux-gnu --prefix=/tmp/protobuf-cache/3.19.2/Linux-aarch_64
checking build system type... x86_64-pc-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking target system type... aarch64-unknown-linux-gnu
checking for aarch64-linux-gnu-gcc... aarch64-linux-gnu-gcc
**checking whether we are cross compiling... yes**

[sumitd2]

exe was built successfully. Are we using the wrong objdump?

> Task :grpc-compiler:checkArtifacts FAILED

Checking format of build/artifacts/java_plugin/protoc-gen-grpc-java.exe
Format=elf64-little
Assertion failed:  "elf64-little" == "elf64-powerpcle"
File "check-artifact.sh", line 65

FAILURE: Build failed with an exception.

[ejona86]

Oh, it is close!

Hmmm... That's an explicit check in the check-artifact.sh script. It does seem broken that arm and ppc would have the same string. Line 55 does call objdump without a prefix.

[sumitd2]

@ejona86
Confirmed, its the wrong objdump. Appended is the output for power exe on x86.
Have put in a fix.

[root@acs-x86-node1-ghatwala-rhel sumit]# objdump -f protoc-gen-grpc-java
protoc-gen-grpc-java:     file format elf64-little
architecture: UNKNOWN!, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000010008628

[sumitd2]

@ejona86 Looks like the Bazel build failed due to a JVM crash. All else LGTM.

[ejona86]

The change in check-artifacts for getting the format should probably be cleaned up in the future, but we can do that later.

[sanjaypujare]

LGTM