LO 7.0 fails to start with --nologo

users
#1

I saw this error when I tried to start LO 7.0 Calc from the command line:

$ /usr/bin/libreoffice --calc --nologo
/usr/bin/libreoffice: 191: exec: /usr/bin/oosplash: not found

I located oosplash and symlinked it to /usr/bin and got this:

$ sudo ln -s /opt/libreoffice7.0/program/oosplash /usr/bin/oosplash
$ /usr/bin/libreoffice --calc --nologo
Warning: failed to launch javaldx - java may not function correctly
ERROR 4 forking process

This makes 7.0 completely unusable for me. What changed in the Java
support? I didn't see anything directly related to this in the
release notes.

Suggestions?

Thanks.

Mark

#2

I forgot to mention - I'm running this on Xubuntu 18.04.4.

Mark

#3

I can't reproduce this error in virtual machine with Xubuntu 18.04

mau@xubuntu $ soffice --calc --nologo

Fresh install

Please, always reply to list

#4

Well whatever he was replying to isn't on list either, so is the pot
calling the kettle black? And why didn't you quote what he was replying
to?

#5

Let's not make this a silly war of who should have done what.

Update on my original problem: I added a symlink to oosplash in
/usr/bin and, other than the java runtime error, it now comes up and
runs just fine - writer and calc (the two I mainly use).

I'm not sure what the java problem is, but it's not impacting my work.
It would be nice to see it fixed someday.

Mark

#6

I think oosplash is not part of LibreOffice 7.0

(It is not present under my Windows installation, and not on my Ubuntu18 system)

#7

On Ubuntu18 i am getting:

$ /usr/local/bin/libreoffice7.0 --calc --nologo
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx

And, after that calc starts normally.

Your installation seems to be defective? or it is having remains of another/older office product.

#8

oosplash is a Linux-only part of LO.

What looks suspicious with the original post is that they have a /usr/bin/libreoffice, which is not something that an upstream TDF LO would normally install. So this rather looks like an issue with how they obtained and installed LO (presumably from their distro).

#9

[Please do not turn this into a private conversation by dropping the mailing list; added it back now]

What looks suspicious with the original post is that they have a
/usr/bin/libreoffice, which is not something that an upstream TDF LO
would normally install. So this rather looks like an issue with how
they obtained and installed LO (presumably from their distro).

/usr/bin/libreoffice is a symlink I add so I can use a keyboard
shortcut to run writer or calc without having to change the shortcut
everytime a new major release comes out.

Like so:

lrwxrwxrwx 1 root root 23 Sep 3 14:55 /usr/bin/libreoffice ->
/usr/bin/libreoffice7.0*
lrwxrwxrwx 1 root root 35 Feb 28 2020 /usr/bin/libreoffice6.4 ->
/opt/libreoffice6.4/program/soffice*
lrwxrwxrwx 1 root root 35 Sep 3 14:57 /usr/bin/libreoffice7.0 ->
/opt/libreoffice7.0/program/soffice*

I trust you are not saying that using a symlink will break something
in the binaries - that would be tragic.

soffice is a shell script that tries to determine its location in the file system, so that it can call other executables like oosplash and javaldx next to itself. See the section labelled with a "resolve installation directory" comment determining the sd_prog variable, which shall resolve to the actual directory containing the soffice shell script, with any symlinks resolved.

The "double symlink" scenario you outline above works e.g. fine for me on Fedora 32. You need to debug into that shell script code to see why it breaks for you.

#10

:

soffice is a shell script that tries to determine its location in the
file system, so that it can call other executables like oosplash and
javaldx next to itself. See the section labelled with a "resolve
installation directory" comment determining the sd_prog variable, which
shall resolve to the actual directory containing the soffice shell
script, with any symlinks resolved.

The "double symlink" scenario you outline above works e.g. fine for me
on Fedora 32. You need to debug into that shell script code to see why
it breaks for you.

Thanks for the suggestion.

I ran the command as "bash -x /usr/bin/libreoffice --calc --nologo"
and everything works fine down to the following (last) command, which
opens calc with no logo. However notice what also appears:

+ exec /opt/libreoffice7.0/program/oosplash --calc --nologo
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx

oosplash is an ELF binary that actually runs (all?) the LibreOffice
programs. While that seems obscure enough for me, the problem (not
finding a java runtime system) has nothing to do with the symlinks I
have set up for my keyboard shortcuts so they work independent of
where LO actually lives on my machine.

I don't know why this is happening, but I do know it has been going on
at least since LO 5, and there have been many many comments on this
email list about it being a bug, to which I agree.

I have not seen any errors or other impact of this problem - maybe I
don't use the JRE enough, or the errors are invisible for everything I
am doing, and I find it disturbing that this keeps getting reported
and not fixed.

That said, I consider my problem resolved - no need for further input
here. If someone wants to comment on the JRE issue, please post in a
new thread, don't complicate this one.

Thanks.

Mark