jitsi fails to find libjawt.so on ubuntu linux using the provided packages

[callegar]

Launching jitsi on debian/ubuntu results in an error being reported on stderr:

2017-09-12 10:05:47.066 SEVERE: [21] org.jitsi.impl.neomedia.device.DeviceConfiguration.log() Failed to register custom Renderer org.jitsi.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer with JMF.
java.lang.UnsatisfiedLinkError: /tmp/jna--172125263/jna3728938959406524053.tmp: libjawt.so: cannot open shared object file: No such file or directory

This seems to be caused by the fact that the jitsi startup shell script /usr/bin/jitsi changes the LD_LIBRARY_PATH and forgets to re-add the jre library path (that is usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/ in my system) to it.

Editing the script to assure that the jre library path is included in LD_LIBRARY_PATH prevents the "SEVERE" error from being issued at startup.

I have experimented by editing /usr/bin/jitsi to add usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/ to LD_LIBRARY_PATH and this works. For the sake of rapidity, I have used a hardwired path, but the script should probably look at which jre is being used and where its lib dir is in the filesystem.

[ibauersachs]

This can't be a generic problem:

• The script extends LD_LIBRARY_PATH (line 39), it doesn't replace it
• It works fine on e.g. Ubuntu 16.04

We'll also need your entire logs. Or, at the very least:

• the version of Jitsi you were using
• the property value of
  • sun.boot.library.path
  • java.library.path
  • jna.library.path

[callegar]

The problem seems to be rather common. Searching jitsi and libjawt on google returns many results. Interestingly, if you look at bug reports for many distros, even when reporting other problems, if the stderr output is included you see that there was a failure in finding libjawt.so. For instance:

http://users.sip-communicator.dev.java.narkive.com/1In2eKM6/jitsi-users-jitsi-can-draw-no-graphics-on-ubuntu-12-04
jitsi/jitsi-meet#242
http://lists.jitsi.org/pipermail/users/2014-February/006365.html

Incidentally, I am on Kubuntu 17.04.

I think I was wrong in stating in my first report that the jitsi startup script fails to "re-" add the the jre library path to LD_LIBRARY_PATH, since it is evidently not included from the beginning.

From java -XshowSettings:properties I get:

Property settings:
    awt.toolkit = sun.awt.X11.XToolkit
    file.encoding = UTF-8
    file.encoding.pkg = sun.io
    file.separator = /
    java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
    java.awt.printerjob = sun.print.PSPrinterJob
    java.class.path = .
    java.class.version = 52.0
    java.endorsed.dirs = /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/endorsed
    java.ext.dirs = /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext
        /usr/java/packages/lib/ext
    java.home = /usr/lib/jvm/java-8-openjdk-amd64/jre
    java.io.tmpdir = /tmp
    java.library.path = /usr/local/lib
        /home/callegar/lib
        /home/callegar/lib32
        /usr/java/packages/lib/amd64
        /usr/lib/x86_64-linux-gnu/jni
        /lib/x86_64-linux-gnu
        /usr/lib/x86_64-linux-gnu
        /usr/lib/jni
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_131-8u131-b11-2ubuntu1.17.04.3-b11
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 1.8
    java.vendor = Oracle Corporation
    java.vendor.url = http://java.oracle.com/
    java.vendor.url.bug = http://bugreport.sun.com/bugreport/
    java.version = 1.8.0_131
    java.vm.info = mixed mode
    java.vm.name = OpenJDK 64-Bit Server VM
    java.vm.specification.name = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 1.8
    java.vm.vendor = Oracle Corporation
    java.vm.version = 25.131-b11
    line.separator = \n 
    os.arch = amd64
    os.name = Linux
    os.version = 4.10.0-35-generic
    path.separator = :
    sun.arch.data.model = 64
    sun.boot.class.path = /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/resources.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/sunrsasign.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jsse.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jce.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/charsets.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jfr.jar
        /usr/lib/jvm/java-8-openjdk-amd64/jre/classes
    sun.boot.library.path = /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64
    sun.cpu.endian = little
    sun.cpu.isalist = 
    sun.io.unicode.encoding = UnicodeLittle
    sun.java.launcher = SUN_STANDARD
    sun.jnu.encoding = UTF-8
    sun.management.compiler = HotSpot 64-Bit Tiered Compilers
    sun.os.patch.level = unknown
    user.country = US
    user.dir = /home/callegar
    user.home = /home/callegar
    user.language = en
    user.name = callegar
    user.timezone = 

where the sun.boot.library.path seems correct. Yet the java.library.path includes a /usr/java/packages/lib/amd64 that is not existent on my system.

If I look at the jitsi logs, I get

sun.boot.library.path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64
[...]
java.library.path=/usr/local/lib:/home/callegar/lib:/home/callegar/lib32:/usr/share/jitsi/lib/native:/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
[...]
jna.library.path=/usr/share/jitsi/lib/native

Jitsi is at version 2.11.5594, but I have seen the issue for a very very long time. And jitsi seems to run anyway.

Hope this helps...

[callegar]

I would like to mention also https://bbs.archlinux.org/viewtopic.php?id=124432 which is an old bug to an unrelated piece of java software showing exactly the same issue with the same workaround.

[ComputingFroggy]

I have the same problem (resolved by the same fix) ... and that happened suddenly. It used to work, and this morning, it wasn't anymore.
On my platform (Ubuntu 18.04), LD_LIBRARY_PATH is empty ! !

[traud]

sudo apt install openjdk-8-jre libavcodec-extra libavfilter-extra libappindicator1
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386

issue that in the Terminal and then start jitsi from the very same Terminal. Works here in Ubuntu 18.04 LTS with Jitsi Desktop 2.10 (= stable release as of today).

works fine on e.g. Ubuntu 16.04

Yes, because there, Java 8 is the default runtime environment. On newer Ubuntu (with their newer default Java versions; even when those newer versions are not installed), Java 8 is not in the default path for shared libraries. I fixed this with the following patch:

--- libjitsi/src/native/build.xml	(libjitsi-src-1097.zip)
+++ libjitsi/src/native/build.xml	(working copy)
@@ -254,2 +254,4 @@
       <linkerarg value="-L${system.JAVA_HOME}/jre/lib/amd64" if="is.running.linux" />
+      <linkerarg value="-Wl,-rpath,${system.JAVA_HOME}/jre/lib/i386" if="is.running.linux" />
+      <linkerarg value="-Wl,-rpath,${system.JAVA_HOME}/jre/lib/amd64" if="is.running.linux" />
       <linkerarg value="-Wl,-z,relro" if="is.running.debian"/>

and re-builded that shared library within LibJitsi:

sudo apt install libxv-dev
ant -lib ~/.m2/repository/org/apache/maven/maven-ant-tasks/2.1.3 jawtrenderer
mvn install -Dmaven.test.skip=true

For those interested to compile Jitsi Desktop themselves, see this thread… however, the export command above should be enough for those who simply want to use Jitsi Desktop in Ubuntu 18.04 LTS and Debian Stretch. This patch is just for developers.

[keunes]

Thanks for proposing a solution, @traud. I have Jitsi installed as instructed here and executed your code:

sudo apt install openjdk-8-jre-headless libavcodec-extra libavfilter-extra libappindicator1
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386

However, I get the following error, when executing Jitsi from the terminal:

Exception in thread "main" java.lang.NoSuchFieldError: preferIPv6Address
	at java.base/java.net.InetAddress.init(Native Method)
	at java.base/java.net.InetAddress.<clinit>(InetAddress.java:341)
	at java.base/java.net.NetworkInterface.init(Native Method)
	at java.base/java.net.NetworkInterface.<clinit>(NetworkInterface.java:68)
	at net.java.sip.communicator.util.launchutils.SipCommunicatorLock.getRandomBindAddress(SipCommunicatorLock.java:289)
	at net.java.sip.communicator.util.launchutils.SipCommunicatorLock.lock(SipCommunicatorLock.java:189)
	at net.java.sip.communicator.util.launchutils.SipCommunicatorLock.tryLock(SipCommunicatorLock.java:173)
	at net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:162)

Any idea?

[traud]

If you are unsure, I recommend to create a new issue. Later, issues can be closed/redirected = merged. However, splitting of issues is still complicated in GitHub. In your case, I have no idea. One approach would be to post much more information, for example, what happens when you enter

java -version

Furthermore, your Linux distribution (Ubuntu, Debian, …) and its version would be interesting. Then, an enthusiastic user might try to reproduce your scenario. If the default Java Runtime Environment is not Java 8, you are able to change the default for example via

sudo update-alternatives --config java

If you want to stick with your current Java version, you have to use another path for LD_LIBRARY_PATH, or not using it at all (if you are using default-jre), or going for change #531.

[traud]

Keunes, which Linux distribution do you use? Which Java Runtime Environment was your default?