Skipping GKL library to build picard on multiple CPU architectures

junaruga commented 4 years ago

Instructions

This issue is feature request or bug report.

My friend was trying to build picard on multiple CPU architectures such as arm64, ppc64le and s390x in Debian to build and run igv and artemis on the CPUs.

And I tried to build picard on Travis CI multiple CPU architectures to help the work.

But it seems that the CI was failed because of failing to load GKL library. As it seems that the GKL only supports Intel CPU, I want to see the library is not loaded when building picard on non-Intel CPU architectures.

Seeing the CPU macros document, the logic might be like this.

#if defined(__x86_64__)
  something /* Intel specific code */
#else
  something
#endif

Bug Report

Affected tool(s)

igv
artemis

Affected version(s)

[ ] Latest public release version [version?]
[X] Latest development/master branch as of [date of test?] (2020, 8th, Feburary)

Description

Describe the problem below. Provide screenshots , stacktrace , logs where appropriate.

The Travis logs: https://travis-ci.org/junaruga/picard/builds/647790095

arm64

Gradle suite > Gradle test > picard.IntelInflaterDeflaterLoadTest > testIntelDeflaterIsAvailable FAILED
    java.lang.AssertionError: Intel shared library was not loaded. This could be due to a configuration error, or your system might not support it. expected [true] but found [false]
        at org.testng.Assert.fail(Assert.java:96)
        at org.testng.Assert.failNotEquals(Assert.java:776)
        at org.testng.Assert.assertTrue(Assert.java:44)
        at picard.IntelInflaterDeflaterLoadTest.testIntelDeflaterIsAvailable(IntelInflaterDeflaterLoadTest.java:24
Gradle suite > Gradle test > picard.IntelInflaterDeflaterLoadTest > testIntelInflaterIsAvailable FAILED
    java.lang.AssertionError: Intel shared library was not loaded. This could be due to a configuration error, or your system might not support it. expected [true] but found [false]
        at org.testng.Assert.fail(Assert.java:96)
        at org.testng.Assert.failNotEquals(Assert.java:776)
        at org.testng.Assert.assertTrue(Assert.java:44)
        at picard.IntelInflaterDeflaterLoadTest.testIntelInflaterIsAvailable(IntelInflaterDeflaterLoadTest.java:17)
...
18:37:03.104 INFO  NativeLibraryLoader - Loading libgkl_compression.so from jar:file:/home/travis/.gradle/caches/modules-2/files-2.1/com.intel.gkl/gkl/0.8.5/6a16e6900818618762653cd85bac97f510c167fe/gkl-0.8.5.jar!/com/intel/gkl/native/libgkl_compression.so
...
Results: FAILURE (4582 tests, 4580 successes, 2 failures, 0 skipped)
4582 tests completed, 2 failed

ppc64le

...
18:24:06.741 INFO  NativeLibraryLoader - Loading libgkl_compression.so from jar:file:/home/travis/.gradle/caches/modules-2/files-2.1/com.intel.gkl/gkl/0.8.5/6a16e6900818618762653cd85bac97f510c167fe/gkl-0.8.5.jar!/com/intel/gkl/native/libgkl_compression.so
...
Results: SUCCESS (4582 tests, 4580 successes, 0 failures, 2 skipped)

s390x

> Task :barclayTest
OpenJDK 64-Bit Zero VM warning: You have loaded library /tmp/libgkl_compression7756893420419654040.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

The build has been terminated

Steps to reproduce

Tell us how to reproduce this issue. If possible, include command lines that reproduce the problem and provide a minimal test case.

Fork this repository.
Enabled Travis CI on my forked repository.
Update the .travis.yml like this.

diff --git a/.travis.yml b/.travis.yml
index cddd72142..f37e15a20 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,6 +15,23 @@ jdk:
   - oraclejdk8
   - openjdk8
   - openjdk11
+matrix:
+  include:
+    - arch: arm64
+      dist: xenial
+      jdk: openjdk8
+      env:
+        - RUN_BARCLAY_TESTS=true
+    - arch: ppc64le
+      dist: xenial
+      jdk: openjdk8
+      env:
+        - RUN_BARCLAY_TESTS=true
+    - arch: s390x
+      dist: xenial
+      jdk: openjdk8
+      env:
+        - RUN_BARCLAY_TESTS=true
 before_install:
   - wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
   - sudo apt-get -qq update

See the Travis log,

Expected behavior

The unit tests are passed on The Travis CI arm64, ppc64le and s390x cases.

Actual behavior

Tell us what happens instead

The unit tests are not passed on The Travis CI arm64, ppc64le and s390x cases.

How do you think? Thank you.

lbergelson commented 4 years ago

@junaruga Neat. I've never heard anyone trying to build on some of those before.

It looks like in some of them it's just tests that are failing, and in particular the tests to see if the intel deflater is working.

We attempt to avoid this problem by skipping those tests if the we're not running on what we think is a valid architecture, but our test doesn't seem to be very good.

    private void checkIntelSupported(final String componentName) {
        if (!SystemUtils.IS_OS_LINUX && !SystemUtils.IS_OS_MAC) {
            throw new SkipException(componentName + " is not available on this platform");
        }

        if (SystemUtils.OS_ARCH != null && SystemUtils.OS_ARCH.equals("ppc64le")) {
            throw new SkipException(componentName + " is not available for this architecture");
        }
    }

So we check that we're running on linux or OSX and then we check that we're NOT running on PPC.

SO that's why ppc64le is passing the tests and skipping. I don't know why we didn't check that we WERE running on a specific architecture instead of checking a list to exclude, we should change that.

So of your 3 cases

arm64: this looks like hopefully a simple fix to the tests
ppc64le: this seems to be working as expected
s390x: This is doing something bad that might be hard to fix. It looks like this isn't even getting to the tests because it falls over loading the library. When loading the GKL, it tries to load, and then if java reports that it loaded successfully it uses it, otherwise it doesn't. It looks like it's trying to load it and something bad is happening during loading that doesn't register as a failure but causes things to lock up. That might be trickier fix.

junaruga commented 4 years ago

Hi @lbergelson

Thank you for checking the issue!

SO that's why ppc64le is passing the tests and skipping. I don't know why we didn't check that we WERE running on a specific architecture instead of checking a list to exclude, we should change that.

I see. You have already implemented the logic to skip for non-Intel CPU. You can use the a list to exclude (black list) or you can use a list to include (white list), seeing this article to check Intel CPU.

If SystemUtils.OS_ARCH is "x86", "i386", "i486", "i586" or "i686", it is Intel x86 32-bit If SystemUtils.OS_ARCH is "x86_64" or "amd64", it is Intel x86 64-bit

So of your 3 cases

Thank you for checking the 3 cases. It's really great if those are fixed. Nowadays some Linux distributions have an availability for multiple CPUs. Red Hat Enterprise Linux 8 was released at May 7th 2019, supporting 4 CPUs x86_64, aarch64 (arm64), ppc64le, s390x. Wikipedia, Release note. I have a chance to use aarch64 (arm64) base HPC montblanc.

broadinstitute / picard