Comment 18 for bug 1662813

> It seems that this issue was fixed on 1.136 (https://jenkins.io/changelog/)
> The s390x libs haven't been included in the shipped library prior to, a system install was required at that time.

Right, that would explain why it would not work prior to that.

> Anyhow, the locally installed libraries should be available and in the path.
> Otherwise, changing the location/adding a link wouldn't have fixe the issue.

The libraries are available in the path, only not with the default
name, and that is intentional. The libjna packages in Debian/Ubuntu
are designed to:
1. be used by application that don't embed their own jna jar file
2. prevent Debian/Ubuntu's libjnidispatch library from being loaded
when the application provides its own jna jar file, otherwise there's
a high chance of a version conflict

The above reasons is why the library is called
"libjnidispatch.system.so" instead of "libjnidispatch.so". The main
discussion on this is, as you pointed, in Debian bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858876

Any third party including their own jna.jar is responsible for
supporting it, from the java class to the arch native libraries.

Jenkins could improve on this by replacing embedded jars and libraries
with the ones packaged on Debian/Ubuntu, specially on the cases of
native libraries. Or, should they prefer to keep embedding the native
libraries, their package should move from "Architecture: all" to only
declaring the supported architectures.