Closed fitzsim closed 7 months ago
Sctp is now building its libraries automatically using GitHub actions, including for linux-ppc64le.
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.
The new sctp is in jitsi-videobridge v2.3-88-g0c54ff7c, just uploaded to our Maven and unstable APT repositories.
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.
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.
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.
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.
I guess jitsi-srtp could use the same GitHub Actions treatment that jitsi-sctp received? Further discussion could happen on https://github.com/jitsi/jitsi-srtp/pull/49
Thanks again for fixing jitsi-sctp on ppc64le.
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 theusrsctp
directory and checked out revisionc1d6cb3bf4344e01e7d0b3157f4e7103d55b0fbf
.Then I created the target directory:
mkdir -p jniwrapper/native/src/main/resources/lib/linux-ppc64le
otherwise the
mvn package
step would fail with:Then I ran:
mvn package -DbuildSctp -DbuildNativeWrapper -DdeployNewJnilib
which built the library then failed with:
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.