Build linux-ppc64le native library, with usrsctp tag c1d6cb3bf4344e01e7d0b3157f4e7103d55b0fbf

[fitzsim]

Here are binaries for GNU/Linux ppc64-little-endian systems, built on my Debian 12 ppc64le machine.

Here are notes on how I built them:

First I cloned usrsctp into the usrsctp directory and checked out revision c1d6cb3bf4344e01e7d0b3157f4e7103d55b0fbf.

Then I created the target directory:

mkdir -p jniwrapper/native/src/main/resources/lib/linux-ppc64le

otherwise the mvn package step would fail with:

cp: cannot create regular file '[...]/jniwrapper/native/src/main/resources/lib/linux-ppc64le/libjnisctp.so': No such file or directory

Then I ran:

mvn package -DbuildSctp -DbuildNativeWrapper -DdeployNewJnilib

which built the library then failed with:

SEVERE: Error loading native library: 
java.io.FileNotFoundException: File /lib/linux-ppc64le/libjnisctp.so was not found inside JAR.

At this point, I could have re-run the same mvn package command and it would have found the shared library. Instead, I did:

cp -a jniwrapper/native/src/main/resources/lib/linux-ppc64le jniwrapper/native/src/main/resources/lib/linux-ppc64el

to support Ubuntu systems that may refer to "ppc64le" as "ppc64el".

Then I re-ran:

mvn package -DbuildSctp -DbuildNativeWrapper -DdeployNewJnilib

and it found both the linux-ppc64le and linux-ppc64el directories and included them in the jars.

I noticed that paths including my home directory got leaked into libjnisctp.so, so it may be good to rebuild the ppc64-little-endian libjnisctp.so on an official ppc64le or ppc64el Jitsi build server.

[JonathanLennox]

Sctp is now building its libraries automatically using GitHub actions, including for linux-ppc64le.

[fitzsim]

Thank you for the update, @JonathanLennox. I subscribed to the nightly APT repo at download.jitsi.org; as of today, the latest, 2.3-87-gf0e4f851-1, does not have the changes, but I will keep updating until I can confirm the new sctp jar file works. In the meantime, I found the GitHub Actions artifact; the new path, linux-ppc64le/libjnisctp.so, looks like it will work on my system. I suspect I will have to wait for it to hit nightly to test though, due to the sctp file reorganization.

[JonathanLennox]

The new sctp is in jitsi-videobridge v2.3-88-g0c54ff7c, just uploaded to our Maven and unstable APT repositories.

[fitzsim]

sctp looks good! Here are the relevant logs during a meeting (after I deleted the non-bundled JNI libraries I had lying around from prior tests, which take priority.): JVB 2024-02-23 15:41:40.712 INFO: [83] SctpManager.<clinit>#62: Initializing Sctp4j JVB 2024-02-23 15:41:40.775 INFO: [83] SctpJni.<clinit>#30: SCTP lib loaded JVB 2024-02-23 15:41:40.776 INFO: [83] SctpJni.logInfo#178: org_jitsi_modified_sctp4j_SctpJni.c calling init Now I have to work around, on this latest version, this one: JVB 2024-02-23 15:41:41.307 INFO: [83] [...] SctpSocket.onNotification#207: sctp is now up. was ready=false JVB 2024-02-23 15:41:41.324 WARNING: [123] JitsiOpenSslProvider.<clinit>#66: Unable to load jitsisrtp java.lang.UnsatisfiedLinkError: no jitsisrtp_3 in java.library.path: /usr/java/packages/lib:/usr/lib/powerpc64le-linux-gnu/jni:/lib/powerpc64le-linux-gnu:/usr/lib/powerpc64le-linux-gnu:/usr/lib/jni:/lib:/usr/lib [...] That might be something to do with Debian 12. I have worked around it before but I do not remember the cause right now. I will file another PR if necessary, after I investigate.

[fitzsim]

Workaround: rename linux-ppc64el to linux-ppc64le inside /usr/share/jitsi-videobridge/lib/jitsi-srtp-1.1-15-ga19c05a.jar Now: JVB 2024-02-23 18:37:24.221 INFO: [118] JitsiOpenSslProvider.<clinit>#52: jitsisrtp successfully loaded for OpenSSL 3 I guess jitsi-srtp could use the same GitHub Actions treatment that jitsi-sctp received? Further discussion could happen on jitsi/jitsi-srtp#49 Thanks again for fixing jitsi-sctp on ppc64le.