Sigil 2.7.0 crashes

[DiapDealer]

You should just go back to the original launch script (/usr/bin/sigil). It's correct. Just reinstall Sigil to recreate it.

The following line in your modified launch script is not syntactically correct:

export LD_LIBRARY_PATH="$SIGIL_LIB_DIR${LD_LIBRARY_PATH:+ :$LD_LIBRARY_PATH}"

It should be:

export LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$LD_LIBRARY_PATH"

Adding the /etc/ld.so.conf.d/sigil.conf may fix whatever is incorrect on your system, but it's not necessary for a working Sigil installation from the Arch repositories--with any version.

I won't try to convince to to get it properly straightened out if you're fine with your current bandaid, but I worry it will cause other problems down the road.

[KevinH]

Your edited script version ignores setting the QTLIB dir into the LD_LIBRARY_PATH as this original piece did:

QTLIB_DIR="/usr/lib"
SIGIL_BIN_DIR="/usr/lib/sigil"

if [ -z "$LD_LIBRARY_PATH" ]; then
LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR"
else
LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR:$LD_LIB RARY_PATH"
fi

My guess is this change may also be related to the issue you are seeing.

[DiapDealer]

Adding the Qt libs directory to the ld_library_path is really only strictly necessary if you custom build Sigil against a version of Qt different than the system's default Qt. The repo version of Sigil is always built against the current system Qt (and should always be able to find it). It doesn't hurt to include the system Qt libs directory though. That's why I include it in the vanilla launcher--it will work for all situations: vanilla or custom.

I'd just like to see Reuben return to a completely stock distro Sigil installation so we can properly debug what might have been happening.

[RbnJrg]

Originally Posted by DiapDealer

Adding the Qt libs directory to the ld_library_path is really only strictly necessary if you custom build Sigil against a version of Qt different than the system's default Qt. The repo version of Sigil is always built against the current system Qt (and should always be able to find it). It doesn't hurt to include the system Qt libs directory though. That's why I include it in the vanilla launcher--it will work for all situations: vanilla or custom.

I'd just like to see Reuben return to a completely stock distro Sigil installation so we can properly debug what might have been happening.

I reinstalled Sigil, the /usr/bin/sigil script now is:

#!/bin/sh

# Entry point for Sigil on Unix systems.
# Adds linked Qt's lib directory to the LD_LIBRARY_PATH

QTLIB_DIR="/usr/lib"
SIGIL_BIN_DIR="/usr/lib/sigil"

if [ -z "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR"
else
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR:$LD_LIBRARY_PATH"
fi

# Create an environment var for the Sigil share directory location.
if [ -z "$SIGIL_SHARE_PREFIX" ]; then
  SIGIL_SHARE_PREFIX="/usr"
  export SIGIL_SHARE_PREFIX
fi

# Not really needed anymore but left in for fringe cases
#if [ -z "$SIGIL_EXTRA_ROOT" ]; then
#  SIGIL_EXTRA_ROOT="/usr/share/sigil"
#  export SIGIL_EXTRA_ROOT
#fi

export LD_LIBRARY_PATH

exec /usr/lib/sigil/sigil "$@"

I also removed the sigil.conf file and... Sigil crashes again in my system. For an unknown reason, Sigil can't find the gumbo library.

[DiapDealer]

Can you give us the exact error message you get when you launch Sigil from a terminal using:

/usr/bin/sigil

EDIT: I updated to Qt 6.10.1 on my Arch system and now I get the warning about the QDBUS error as well. But it appears to be cosmetic as it doesn't prevent Sigil from launching and functioning. I'll look into why it's happening, but I don't consider it a priority issue.

But why the setting of LD_LIBRARY PATH in /usr/bin/sigil doesn't allow Sigil to find libsigilgumbo just doesn't make any sense to me. Something else has to be going on that we are missing.

[KevinH]

Manjaro stable now has Qt 6.10.1 and Sigil 2.7.0, tried running /usr/bin/sigil and it all worked just fine. No QDBUS warnings either.

The only thing I can think of that fits the clues might be a leftover libsigilgumbo.so someplace? Maybe in /usr/lib? But that seems highly unlikely.

[DiapDealer]

You have KDE/Plasma, right? I think there's been some changes to theme detection stuff in Qt6.10.1. I'm seeing lots of new background warnings when changing themes in Cinnamon. Sigil's themes/palettes are still properly changing on the fly however, so no worries there. I think maybe they're (Qt) starting to move toward proper use of the xdg portal stuff to detect changes instead of their older hackery. That sort of stuff seems to have been working naturally for a while now with KDE. Cinnamon is only Gnome-ish these days, so I expect some warnings.

[RbnJrg]

Originally Posted by DiapDealer

Can you give us the exact error message you get when you launch Sigil from a terminal using:

/usr/bin/sigil

With that command from CLI, Sigil starts fine, but with the message:

Warning: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID")

And once I get the program to start, I can then continue to start it with the launcher without it freezing. Weird.

[KevinH]

Could the launcher somehow NOT point to /usr/bin/sigil ?

[DiapDealer]

Originally Posted by KevinH

Could the launcher somehow NOT point to /usr/bin/sigil ?

That's my only thought. If a desktop/menu shortcut is somehow pointing to /usr/lib/sigil/sigil instead of /usr/bin/sigil, it would certainly cause problems. Or perhaps another script (.profile or .bash) is somehow diddling LD_LIBRARY_PATH and interfering? I just know that absolutely nothing has changed with Sigil 2.7.0 in this regard. And nothing has changed with how Arch is packaging Sigil 2.7.0 compared to older versions. There are also no other bug reports of this nature (on Arch or Github) with regard to Sigil 2.7.0.

[DiapDealer]

Or maybe /usr/lib/sigil has been added to $PATH? That could cause weirdness too.

But Reuben confirmed upthread that 'which sigil' only returns /usr/bin/sigil.

I don't know exactly how the desktop launcher he's using was created (or where it's actually located). Any application launchers in ~/.local/share/applications should override the ones in /usr/share/applications or /usr/local/share/applications.

He's added the QT_QUICK_BACKEND env var to the .desktop file (I remember helping him do that in the past), but I don't recall where it actually resides on his system.

[RbnJrg]

I employ the following launcher:

[Desktop Entry]
Type=Application
Name=Sigil
Comment=ePUB file editor
TryExec=sigil
Exec=env QT_QUICK_BACKEND=software sigil %F
Icon=sigil
Categories=Office;
MimeType=application/epub+zip;
Path=
Terminal=false
StartupNotify=true

And not, the /usr/lib/sigil value has not been added to $PATH.

[DiapDealer]

Where does that .desktop file reside?

[RbnJrg]

Originally Posted by DiapDealer

Where does that .desktop file reside?

In /home/ruben/Desktop/ with the others launchers I have.

And I had a new crash by trying to open Sigil with the launcher and after starting it with the CLI (/usr/bin/sigil), the program opened fine but this time with the message:

ERROR:block_files.cc(450)] Failed to open /home/ruben/.local/share/sigil-ebook/sigil/local-storage/DawnWebGPUCache/data_0

Maybe that can be a clue.

[KevinH]

That tells us that your launcher is somehow not invoking sigil as it should because a software only version of of the Sigil backend would never need to use the local storage for a DawnWebGPUCache since it would not be using the accelerated GPU since you told it to use software only.

First check out the permissions on this folder and its contents:

/home/ruben/.local/share/sigil-ebook/sigil/local-storage/

And make sure you have write read, write privs on that folder and all its contents. (and execute privs since it is a folder)


If permissions are correct, then try deleting that folder

/home/ruben/.local/share/sigil-ebook/sigil/local-storage/

as that local-storage folder should be properly recreated by Sigil if it needs it.

Does that change anything?