Ship libdcsctp4j.so for ppc64le

[fitzsim]

While verifying jitsi/jitsi-srtp#49 I noticed that dcsctp4j does not yet have native objects for ppc64le:

$ dpkg -S /usr/share/jitsi-videobridge/lib/jitsi-dcsctp-1.0-3-gaf9d564.jar
jitsi-videobridge2: /usr/share/jitsi-videobridge/lib/jitsi-dcsctp-1.0-3-gaf9d564.jar
$ dpkg -l | grep jitsi-videobridge2
ii  jitsi-videobridge2  2.3-150-gb67f0c0d-1  all  WebRTC compatible Selective Forwarding Unit (SFU)
$ jar tf /usr/share/jitsi-videobridge/lib/jitsi-dcsctp-1.0-3-gaf9d564.jar | grep '.so$'
linux-aarch64/libdcsctp4j.so
linux-x86-64/libdcsctp4j.so

Are there plans to include ppc64le binaries at some point?

[JonathanLennox]

Unfortunately, the dcsctp library comes from Google's libwebrtc, which does not support building on PPC.

I know that Debian has a patchset to build libwebrtc on PPC, but I don't know how hard it would be to adapt to the build process we're using, which pulls from the main Google repo.

[fitzsim]

Ah, I see, thanks. Is there an upstream feature request for ppc64le support we can link to here? If `dcsctp4j` is mandatory for Jitsi now, I will try to figure out the best way to make it work on Debian ppc64le, in lieu of upstream support.

[aaronkvanmeerten]

As a note, it is still possible to use the usrsctp library via user configuration options, so we suggest users who require both SCTP and PPC use that method instead of dcsctp.

[JonathanLennox]

I think the WebRTC issue to support ppc is at https://issues.webrtc.org/issues/42224432, though it's currently marked "wontfix".

[fitzsim]

Thank you for the link; that looks like a patch for big-endian support. But the WebRTC maintainer seems receptive to a working patch for ppc64 and/or ppc64le. Jitsi would be a good "test case" to help validate a proposed upstream patch. (Not suggesting Jitsi maintainers work on this, just pointing it out to others who may read this.) Also good to know about the `usrsctp` configuration option, thank you.

[tpearson-ssc]

I'm the maintainer of the Debian patchset; we just hit this on multiple servers due to the Jitsi change to dcsctp. How can I help with support?

[fitzsim]

I am trying to get Jitsi working again on ppc64le, and I have now hit:

java.lang.NoClassDefFoundError: Could not initialize class org.jitsi.dcsctp4j.DcSctpOptions
[...]
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: no dcsctp4j in java.library.path

I am attempting to build the dcsctp4 native binaries from source, and I hit:

$ resources/ubuntu-build-all.sh ~/DepotTools ~/WebRTC
[...]
/src/dcsctp4j/resources/checkout-webrtc.sh: line 54: fetch: command not found

At this point I will attempt to hack my checkout to build against the Debian WebRTC development package, so as to avoid the large checkout of a Google repository and to avoid the need to install (apparently custom?) fetch and gclient commands, which I do not have already-installed.

[JonathanLennox]

fetch and gclient are from Google's depot_tools, and are their standard ways of checking out the source to the webrtc native libraries.

checkout-webrtc.sh should have checked them out and added them to your PATH, so I'm surprised it's not finding them, assuming it didn't fail. Can you run with bash -x resources/ubuntu-build-all.sh ~/DepotTools ~/WebRTC and see if it's failing?

That said, the WebRTC library as shipped by Google doesn't support ppc64le, so the script ultimately won't work for you anyway. You may be able to build it using the Debian patched version, but I'm not sure.

Our build process automatically rebuilds the libraries on our build machines at each commit to main, so to get ppc support into main, we'd need to make it possible to apply the patches automatically, including being able to cross-build (since we don't have PPC build machines).

Given all that, a simpler fix would be to just change the default jitsi-videobridge configuration to use usrsctp rather than dcsctp on ppc64le, since that's still supported.

[fitzsim]

OK, thank you @JonathanLennox. Are you able to paste the configuration fragment required to use usrsctp instead?

Separately, if dcsctp4j is the "way forward" then I also would like to draw a line around the codee changes required for ppc64le, but I cannot find a standalone Debian libwebrtc package. I did find libtgowt-dev which has some of the correct headers, and does build some files successfully, but the build ultimately fails I guess because it is not the precise version required by libdcsctp4j.so.

Can someone please paste a URL to the libwebrtc Debian ppc64le patch set? I searched the web and Debian repositories but failed to find it. Thank you for the checkout-webrtc.sh advice; I am not sure why it failed, but I skipped over it for the reasons you pointed out, and am instead trying the approach of making the ppc64le library and headers available to the dcsctp4j build.

[JonathanLennox]

This pull request should automatically modify the videobridge config file on Debian/ppc64le to use usrsctp: jitsi/jitsi-videobridge#2214. Please let me know if that works, or if you see any issues with it.

If you want to modify the config file manually, the hocon config path is videobridge.sctp.use-usrsctp; set it to true.

The Debian patches for libwebrtc seem to be part of the Debian Chromium package. See https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/ppc64le?ref_type=heads . (I think these patches may only support native ppc64le builds, though, not cross-compilation?)

[fitzsim]

Thank you! When I get the next chance to work on my configuration I will try installing Jitsi from scratch from the nightly apt source and let you know if the hocon logic works on ppc64le.

[tpearson-ssc]

Our build process automatically rebuilds the libraries on our build machines at each commit to main, so to get ppc support into main, we'd need to make it possible to apply the patches automatically, including being able to cross-build (since we don't have PPC build machines).

Given all that, a simpler fix would be to just change the default jitsi-videobridge configuration to use usrsctp rather than dcsctp on ppc64le, since that's still supported.

I'm very nervous about this; if we are the only user of usrsctp support could be dropped at any point with no warning. If I can assign an individual or team to maintain the ppc64el patches for dcsctp on your infrastructure (or provide native ppc64el build infrastructure) is that an option?

[fitzsim]

SBCL recently pushed a commit to use GitHub Actions to build on Debian ppc64le using QEMU: sbcl/sbcl@062128c. Maybe that approach could work for dcsctp4j's continuous integration.