Description: The "current" basic AppImage fails to start: $ ./LibreOffice-24.2.3.2.basic-x86_64.AppImage /tmp/.mount_LibreO8QH3jn/opt/libreoffice24.2/program/soffice.bin: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory I've run the same "download, chmod u+x, run" test on the last few basic appimages - the results are: LibreOffice-24.2.0.3.basic-x86_64.AppImage success LibreOffice-24.2.1.2.basic-x86_64.AppImage success LibreOffice-24.2.2.2.basic-x86_64.AppImage fail LibreOffice-24.2.3.2.basic-x86_64.AppImage fail LibreOffice-24.2.basic-x86_64.AppImage (points to 24.2.3.2) fail LibreOfficeDev-24.8.0.0.alpha0.basic-x86_64.AppImage success I'm going to make the assumption that if 3 of these versions work then the problem is not with my machine. Steps to Reproduce: 1. Download the AppImage from https://appimages.libreitalia.org/ 2. Check the AppImage's md5sum 3. chmod u+x it 4. Run it. Actual Results: For the 2 failing versions (3 if you include the "current" pointer), LibreOffice fails to start. You get "error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory". Expected Results: The failing versions should not fail - they should start (just like the versions before and the version after). Reproducible: Always User Profile Reset: Yes Additional Info: I can't copy the information from menu Help - About LibreOffice because LibreOffice won't start.
LibreOffice-24.2.4.2.basic-x86_64.AppImage fails too.
I am able to run the 24.2.4 AppImage on Ubuntu 22.04 + GNOME 42.9: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Can you give more details about your system? Have you tested other packaging of LibreOffice?
# Can you give more details about your system? Sure. I run Debian GNU/Linux 12 (bookworm) on linux kernel 6.1.0-21-amd64. I run xorg from the main debian repo with a self-compiled bspwm. The important bit is that I do NOT have any libxslt packages installed: $ dpkg -l | grep -i libxslt | wc -l 0 Could you please check whether you have any libxslt packages installed? That would explain why you *can* run the AppImage while I *cannot*. If you do have a libxslt package installed, you will need to uninstall it to be able to reproduce this bug. (You need to stop the AppImage from using your "pre-installed" library. I do not know whether it is possible to stop the AppImage from using your pre-installed library without uninstalling this library.) This sounds like it *might* just be a "violation" of "Condition 2" on https://docs.appimage.org/reference/best-practices.html: "The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on." (*perhaps* the AppImage does not include libxslt but this is not a problem for you because you have this library pre-installed whereas I do *not* have this library pre-installed.) # Have you tested other packaging of LibreOffice? What other packaging are you referring to? (I have only tested the 7x AppImages that I mentioned.) Merci bcp.
[Automated Action] NeedInfo-To-Unconfirmed
Yup, I've just done a bit more testing, and I was right: # (to be run in an appropriate shell) mkdir AppImageTest && cd $_ url=https://appimages.libreitalia.org/LibreOffice-24.2.1.2.basic-x86_64.AppImage wget $url -O good && chmod u+x ./good && ./good --appimage-extract && \ find . -iname '*libxslt*' | wc -l && rm -rf good squashfs-root/ # prints 1 url=https://appimages.libreitalia.org/LibreOffice-24.2.2.2.basic-x86_64.AppImage wget $url -O bad && chmod u+x ./bad && ./bad --appimage-extract && \ find . -iname '*libxslt*' | wc -l && rm -rf bad squashfs-root/ # prints 0 In other words: https://appimages.libreitalia.org/LibreOffice-24.2.1.2.basic-x86_64.AppImage contains an xslt library. https://appimages.libreitalia.org/LibreOffice-24.2.2.2.basic-x86_64.AppImage does *not* contain an xslt library. HTH.