Yes, you've already mentioned it. It's why I'd consider it a broken package until it's packaged/re-packaged into x86_64 txz.

This is not nearly enough info, what does it say when started from command line? It should tell you exactly what the problem is.
Maybe PM AlienBob if he wants to help. I really can't help you with those binaries, thought you were using a SBo script.

Look at my original post. It includes a complete printout of the error messages.

If you google that particular error message, you will see that this LO library, libuno_sal.so, has a history of making bad java calls for a variety of reasons.

No, I've read it.
There no command in your [code] output.
So "it aborts while trying" is not very specific is it?

Maybe. Just saying I've always had better luck with SBo than binaries, but feel free to use whatever works best for you.

Actually I tried with several different commands: lowriter, localc, soffice. They all behave the same way. The point I was trying to make is that the crash (and it's definitely an "abort", Signal 6) happens a split second after the splash screen comes up. I thought that might be useful information.

Okay, so it's the same output for all of these binaries listed. Is that the same output when both i586 JDK and x86_64 openjdk are installed?
Or when only JDK is installed, or when only openjdk is installed? Or when both JDK and openjdk are removed?

Yes, the output in all cases was identical.

The version of JDK that I downloaded was called jdk-17_linux-x64-bin.tar.gz. AFAIK, Oracle doesn't supply 32-bit JDK any more. The slackbuild that I used to convert it into a slackware package did name that package jdk-17_linux-i586-1.txz but I've already said why I think that happened. It definitely was 64-bit, whatever it was called; I checked some of the libraries with the file command. But in any case, that package was completely removed before I installed Eric's openjre package.

The very first time that I tried to run LO, I didn't have any kind of java on my system. It crashed in precisely that way, so I thought, "It needs java, of course." And I've been going round the mulberry bush ever since.

Assuming those are all different binaries, and same output regardless of JDK/openjdk being installed, I suspect it's 100% LO binary package problem.
This is where one would look for differences between build system used to make a package, and target system used to install a package.
Like I said, I don't use oracle JDK. But this archive could easily be unpacked to /opt/ just like oracle virtualbox.
It's only recommended to package into txz because of doinst.sh and so that the paths are correct for the target system, it can all be done manually just as well.

hazel - I am not sure why you don't want to recompile LibreOffice. I know that you also run LFS. Recompiling is the sure-fire way to fix versioning problems (especially since Java is optional).
Ed

Have you actually looked at the LFS recipe for compiling LibreOffice? It's monstrous! It takes 69 SBU (at least 7 hours on my machine; remember that I use pretty old hardware) and involves several live downloads during the build. Anyway, I used the alien LO in 14.2 and it has always worked just fine for me. If there is a problem with the current version, I'm sure it will be cleared up in due course. Also I can keep up 14.2 even when 15.0 becomes my main system, so I shall always have a working LO available.

I modified the Slackbuild script to do a minimal installation and install in ~/.local

The first run downloads the dependencies and packages them into a tar.xz file. Subsequent runs do not need to download. This is an easy build.

Yes, LibreOffice is a monster to compile, but even 7 hours would have been faster than debugging a binary.
Ed

@hazel:-

Feel free to ignore this suggestion; it's your prerogative, of course, but.....had you ever considered trying the LibreOffice AppImages from their official website?

https://www.libreoffice.org/download/appimage/

I've been using these for several years; primarily in Puppy Linux, but also in various 'buntu- and Slackware-based distros. Without fail, they just "work", all the time, without fuss. Main reason being, I think, that their devs have gone to the trouble to make sure they've been built properly, with absolutely everything LibreOffice needs to function correctly.

(Too many AppImage packagers simply re-package existing .debs, with the result that whatever the application is, it still needs to scamper off into the system to look for dependencies. This goes against the whole principle of AppImages, which is that the package should be built once, and will then run absolutely anywhere.)

I realise this approach probably goes against everything you've ever learnt. As I said, feel free to ignore it.....I probably shouldn't stick my neck out like this in such august company..!


Mike.

You're right that I don't like the idea of appimages. They are almost the opposite of what Unix is about; it's a Windows-like way of doing things. On the other hand LibreOffice, like Firefox, has always been available as a self-contained package. They may be calling it an appimage now, but they were providing such images long before that word was coined.

I think the best policy is to wait and see what happens. After all, I'm not using -current a lot and I have a working LO on Slackware-14. In the mean time, Eric may release a new LO version that works better for me. If it still plays up, downloading from the LO site is still an option.

An update:

I have found a way of experimentally running LO 7.2 in Slackware 14.2 and LO 6.2 in Slackware -current. It involves some black magic with symbolic links and a temporary library path, and I wouldn't recommend it for practical use, but I hoped it would provide me with some diagnostic info. And the results are remarkable.

LO 7.2 starts normally in Slackware 14.2. Whether it continues to work normally, I have no idea, but it certainly doesn't exhibit this buggy behaviour on starting up. Conversely LO 6.2, which has always behaved perfectly in Slackware 14.2, crashes when run in Slackware -current, and the crash messages are identical to those given by 7.2.

So it seems not be an intrinsic LO bug. Rather it's something hostile in my overall Slackware -current environment compared with Slackware 14.2. Now does that give anyone here a glimpse of what might be going wrong?

What was bad in the new environment turned out to be the absence of another of Alien Bob's packages: icu4c-compat. It contains some earlier versions of icu4c (system icu is v.69). I had seen some references to this on Libreoffice forums but assumed that I was OK without it because my soffice.bin binds to the system icu libraries. However it seems that some ancilliary programs don't. I have now installed the -compat package and LO works!