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.
Adding Emiliano. There is an issue tracker for the creation script as well, but maybe we can just use this existing report. https://git.libreitalia.org/libreitalia/loaih/issues
(In reply to Buovjaga from comment #6) > Adding Emiliano. Thanks so much @Buovjaga. Seems to me the OP confirmed the bug, so I would suggest to mark the bug report as "RESOLVED NOTOURBUG" - as the AppImage repository and building pipeline are not maintained directly by TDF (but always happy to discuss a different solution, if TDF decides otherwise). OTOH, though, the issue seems dependent on the fact that libxslt has been removed from the official LO packages (.deb archives) since 24.2.2: $ dpkg -c libobasis24.2-core_24.2.1.2-2_amd64.deb | grep libxslt -rwxrwxr-x root/root 263192 2024-02-25 20:56 ./opt/libreoffice24.2/program/libxslt.so.1 $ dpkg -c libobasis24.2-core_24.2.2.2-2_amd64.deb | grep libxslt $ (I checked: no other .deb in the main .deb archive for 24.2.2 contains the library). FYI, every versions > 24.2.1 on branch 24.2 seems affected. From a security POV, the decision to remove a "static" dependency from inside the packages is indeed the right one - to leverage the user's system package manager to cope with the needed dependency. However, this is an issue for the actual AppImage and its build pipeline: the latter just "extracts" the .deb contents (without installing the .deb package on the system - and this of course fails to install required dependencies via the package manager) and repackages them as AppImage. Similar result can be obtained with the original script. > There is an issue tracker for the creation script as well, > but maybe we can just use this existing report. The report here is indeed precise and clearly points out the nature of the issue. For reference, the issue has been tracked also there and been assigned issue #10: https://git.libreitalia.org/libreitalia/loaih/issues/10 It is open there (so even if it's closed here, the issue is indeed open and I will look into it). For a possible solution: I'm looking into changing the pipeline and the specific AppImage tool to create them (see #159758 or #4 on libreitalia's git). I expect this kind of issues (missing libraries inside AppImages) to be solved or at the very least, highly minimized, once the work has been finished.
(In reply to Emiliano Vavassori from comment #7) > Seems to me the OP confirmed the bug, so I would suggest to mark the bug > report as "RESOLVED NOTOURBUG" - as the AppImage repository and building > pipeline are not maintained directly by TDF (but always happy to discuss a > different solution, if TDF decides otherwise). > > OTOH, though, the issue seems dependent on the fact that libxslt has been > removed from the official LO packages (.deb archives) since 24.2.2: > [...] > From a security POV, the decision to remove a "static" dependency from > inside the packages is indeed the right one - to leverage the user's system > package manager to cope with the needed dependency. > [...] > For reference, the issue has been tracked also there and been assigned issue > #10: > https://git.libreitalia.org/libreitalia/loaih/issues/10 > > It is open there (so even if it's closed here, the issue is indeed open and > I will look into it). Let's close as "not our bug" then, if the packaging decision makes sense on TDF's side. I've added the relevant link in the "URL" field. Thanks everyone, and hopefully https://git.libreitalia.org/libreitalia/loaih/issues/4 will help in the near future!