Jabref: Portable Snapshot does not find libjava.so

[reox]

JabRef version

JabRef 5.0.0-dev--2019-11-03----e356e4910
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 12.0.2

• [x] I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

Steps to reproduce the behavior:

1. Download a portable snapshot for linux
2. unpack
3. run ./bin/JabRef

Will give the following error:

Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.

When running strace, you can see that it does not search for the runtime folder but stops at the lib folder:

[...]
stat("", 0x7ffe79c9cc20)                = -1 ENOENT (No such file or directory)
readlink("/proc/self/exe", "/home/reox/bin/JabRef/bin/JabRef", 4096) = 31
stat("/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned", 0x7ffe79c97330) = -1 ENOENT (No such file or directory)
access("/home/reox/bin/JabRef/lib/libjava.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/reox/bin/JabRef/jre/lib/libjava.so", F_OK) = -1 ENOENT (No such file or directory)
lstat("/usr2", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/reox", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
lstat("/home/reox/bin", {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
lstat("/home/reox/bin/JabRef", {st_mode=S_IFDIR|0755, st_size=63, ...}) = 0
lstat("/home/reox/bin/JabRef/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/reox/bin/JabRef/lib/runtime", {st_mode=S_IFDIR|0755, st_size=63, ...}) = 0
lstat("/home/reox/bin/JabRef/lib/runtime/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/reox/bin/JabRef/lib/runtime/lib/libjli.so", {st_mode=S_IFREG|0644, st_size=79560, ...}) = 0
stat("/home/reox/lib/libjava.so", 0x7ffe79c977e0) = -1 ENOENT (No such file or directory)
write(2, "Error: could not find libjava.so", 32Error: could not find libjava.so) = 32
write(2, "\n", 1
)                       = 1
write(2, "Error: Could not find Java SE Ru"..., 50Error: Could not find Java SE Runtime Environment.) = 50
write(2, "\n", 1
)                       = 1
exit_group(2)                           = ?
+++ exited with 2 +++

I tried the following workaround:

$ cd lib
$ find runtime/lib/ -maxdepth 1 -mindepth 1 -exec ln -s {} \;

which makes jabref start up.

I'm not sure if this problem is specific to CentOS or the current setup on my machine. I also tried it on a fresh Debian stretch VM, where JabRef would start without any problems.
Maybe there is some special ldconfig or environment variable which messes things up?
I can try to test it on a CentOS VM later, or someone has an idea what specific test I could run.

[Siedlerchr]

@LyzardKing do you have any idea what the problem might be?`
Might also be a bug. Then we should report it to the jdk people.
There was also a simliar report in https://github.com/JabRef/jabref/issues/5542#issuecomment-552224289

[LyzardKing]

On Ubuntu I've never had any issue, like in the Debian vm the OP tested..
A while back I tested it on Fedora, I might have a look at that again on the vm..
@reox if you can try on a later centos vm, or a freshly installed one, just to rule out
some strange config on your system..
We can try and debug this..

[LyzardKing]

It works on Fedora 30, I need to download a centos iso to test that, so it'll take a while..

[reox]

I used the CentOS 7 live installer to download JabRef. I could start it without a problem - so the problem is probably the specific configuration.
Does anyone has an idea where to look at? Does the portable version somehow uses ldconfig? I think the installation is quite standard, but I cant be sure...

[koppor]

This is what @DaveJarvis reported at https://github.com/JabRef/jabref/issues/5542#issuecomment-552224289 for Arch Linux (Manjaro)

mkdir -p $HOME/archives
cd $HOME/archives
wget http://builds.jabref.org/master/JabRef-portable_linux.tar.gz
cd $HOME/bin
tar xf ~/archives/JabRef-portable_linux.tar.gz
cd JabRef/bin
$ ./JabRef 
Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.

[reox]

I do not know if you have fixed anything, but on my machine it came good now:

JabRef 5.0.0-dev--2019-11-14----8f7188d2d
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 13.0.1

Looking at strace verifies, that JabRef finds the libjava.so without any problem.

edit: No wait! It looks like the problem is, if jabref is unpacked into a folder like $HOME/bin
I had it unpacked to $HOME/tmp and it works. moving the JabRef folder to $HOME/bin triggers the libjava.so error!
I simply renamed the folder to $HOME/apps and I can start JabRef now without troubles.

[Siedlerchr]

Thanks for your investigation, This seems like a bug in the jpackage tool. Apparently it searches "bin" for the libjava.so and seems to get confused

[tobiasdiez]

I indeed read something about a bug in jpackage when the folder contains bin. Could be already fixed in the latest jpackage update that we use since this morning.

[reox]

I indeed read something about a bug in jpackage when the folder contains bin. Could be already fixed in the latest jpackage update that we use since this morning.

I tested it today with the snapshot from 2019-11-25 and it still fails when Jabref is installed to $HOME/bin.

[koppor]

@reox Could you test with https://builds.jabref.org/master/, because we updated to JDK14 (refs #6145).

[reox]

~/bin$ JabRef/bin/JabRef 
Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.

but this still works:

~/apps$ ./JabRef/bin/JabRef 
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 56 in conversion pattern.
ES2 Prism: Error - reported GLX version = 1.2
    GLX version 1.3 or higher is required

(JabRef:21548): Gdk-WARNING **: 21:29:41.278: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.

Looks like the reported errors do no harm.

JabRef 5.1--2020-03-23--67daf36
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 14

[Siedlerchr]

So the real bug is still present in the jdk. So we should report this

[tobiasdiez]

@Siedlerchr did you already get a response from the java guys?

[koppor]

Is there any JDK issue which we can link here?