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

• 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 #5542 (comment)

[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 #5542 (comment) 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?

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[reox]

this is still an issue in

JabRef 5.3--2021-02-16--5546141
Linux 5.10.0-3-amd64 amd64 
Java 15.0.2 
JavaFX 15.0.1+1

tldr; if jabref portable is put into a folder named bin, it will not start. Other names are fine, like apps

[calixtus]

This seems to be a JVM-bug. @Siedlerchr observing this issue.

[calixtus]

See #5591 (comment) for workaround. Do not put your JabRef installation in a bin directory.

[calixtus]

Maybe related: https://bugs.openjdk.java.net/browse/JDK-8219962
Unfortunately we cannot do anything about this.