Sigil-1.9.10 Released - Page 3

DiapDealer · 05-30-2022, 05:17 PM

I think it's definitely a package problem. It crashes immediately for me -- with almost no output. But when I build Sigil myself (using the exact same system Qt5 version and system glibc), it runs fine.

I use the bundled subprojects that we include in Sigil's source (prce2, minzip, etc) when building, so I guess it could technically be one of those system libraries that their package de-bundles but I doubt it.

New Sigil maintainer over there, so I'll let their in-house bug system protocols play out a bit.

RbnJrg · 05-30-2022, 05:19 PM

Many thanks Kevin, Doitsy and DiapDealer. I really don't know what is the cause of the issue with the official package from Arch; I tried with QTWEBENGINE_DISABLE_SANDBOX=1 and QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" without success. So I built Sigil with the very clear instructions by DiapDealer and now I have a fully functional Sigil 1.9.10

Thank you very much again!

roger64 · 05-31-2022, 06:43 AM

Quote:

Originally Posted by RbnJrg

I can't run Sigil 1.9.10 under Arch Linux; ¿anyone else with the same issue here? (Sigil downloaded from the official repository).

Same. I had a "segmentation fault". I used the archive to reinstall 1.9.2. and, for the time being, blocked any pacman update.

I shall try again later.

KevinH · 05-31-2022, 09:51 AM

FWIW, if you search the gcc.gnu.org bugzilla for "lto" (link time optimizer -flto) you will see a large number of freshly reported lto gcc bugs this month alone and not counting the ones in April or earlier.

Not sure why they add that compiler switch for Sigil, but given it works with lto with Qt6 but not with Qt5, then it is something in Qt5 that probably triggers the gcc bug. So creating a cut-down test case will be a real problem.

Perhaps just dropping the lto switch from the Sigil builds and building with Qt5 might be the safest path forward for Arch. Or using clang?

That said, why is Arch the only one seeing this if the bug is in the latest gcc? Perhaps other distributions actually have the same issue. Does anyone know?

DiapDealer · 05-31-2022, 10:25 AM

Quote:

Originally Posted by KevinH

FWIW, if you search the gcc.gnu.org bugzilla for "lto" (link time optimizer -flto) you will see a large number of freshly reported lto gcc bugs this month alone and not counting the ones in April or earlier.

One of the Arch maintainers mentioned that same thing in the bug report.

Quote:

Originally Posted by KevinH

Not sure why they add that compiler switch for Sigil, but given it works with lto with Qt6 but not with Qt5, then it is something in Qt5 that probably triggers the gcc bug.

I think the switch -flto switch may just be a standard for their packaging. They don't explicitly set it for Sigil, but they always add the following to their cmake config for Sigil:

Code:

-DCMAKE_C_FLAGS:STRING="$CFLAGS" \
-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" \

Quote:

Originally Posted by KevinH

Perhaps just dropping the lto switch from the Sigil builds and building with Qt5 might be the safest path forward for Arch. Or using clang?

I mentioned (in the bug report) that I'm not opposed to them moving to Qt6 for their packages. It has seemed fairly stable for a while now. I've built Sigil with clang on Linux myself, but I've not done a lot of testing. But if it seems sufficient, I'm not opposed to that either. I just don't want to increase the work that debugging issues on Sigil might entail by having packages out there built with clang, gcc, AND qt5 vs qt6.

Quote:

Originally Posted by KevinH

That said, why is Arch the only one seeing this if the bug is in the latest gcc? Perhaps other distributions actually have the same issue. Does anyone know?

Not sure. Perhaps not that many are using the latest version of gcc (or not many are requiring -flto be used to build packages)?

EDIT: and yes from a comment over there, it looks like it's the default to append LTOFLAGS to CXXFLAGS when package building. https://bugs.archlinux.org/task/7487...5&string=sigil

rebski · 06-03-2022, 06:45 AM

I am having instant crashing problems with the update to v1.9.10 on OpenSUSE Tumbleweed, prior to that all was fine. Just wondering if I am alone? Not sure what to do except wait, no doubt it will get fixed in due course.

KevinH · 06-03-2022, 08:31 AM

Quote:

Originally Posted by rebski

I am having instant crashing problems with the update to v1.9.10 on OpenSUSE Tumbleweed, prior to that all was fine. Just wondering if I am alone? Not sure what to do except wait, no doubt it will get fixed in due course.

Have you tried building your own? That appears to work for Arch users.

RbnJrg · 06-03-2022, 11:45 AM

In Windows, I use a light theme, but I have Sigil with the dark theme by setting the enviroment variable SIGIL_USES_DARK_MODE to 1. And it works fine.

In Linux, I also have a light theme and I wanted to put Sigil in "dark mode" by writting in the file /etc/enviroments SIGIL_USES_DARK_MODE=1 but with no result. I also tryed writting in /etc/profile but, no case, Sigil refuses to enter in "dark mode". What am I doing wrong? Many thanks in advance.

BeckyEbook · 06-03-2022, 12:15 PM

@RbnJrg: Try FORCE_SIGIL_DARKMODE_PALETTE

DiapDealer · 06-03-2022, 12:36 PM

Yes. FORCE_SIGIL_DARKMODE_PALETTE=1 should give Sigil the same dark theme as Windows on Linux.

You can also use kvantum and/or qt6ct (or qt5ct if Sigil is built using Qt5) to choose from several different available themes (light or dark).

The idea is to first defer to system/desktop theming on Linux, but allow users to force Sigil to use its inherent dark theme if that's what they wish.

RbnJrg · 06-03-2022, 01:11 PM

Quote:

Originally Posted by BeckyEbook

@RbnJrg: Try FORCE_SIGIL_DARKMODE_PALETTE

Many thanks Becky! FORCE_SIGIL_DARKMODE_PALETTE did the trick

But now I have another issue. I wanted to modify slighly some colors of the dark theme, and changes under Edit/Preferences.../Appareance->CodeView->Item Colors: Custom Color... doesn't work. On Windows I don't have any problem but in Linux seems not to work. Can you (or Diap or Kevin) tell me how to fix that? Thanks.

DiapDealer · 06-03-2022, 01:16 PM

This is the first I've heard of the CodeView custom colors preferences not working under Linux. I'll have to look into it this weekend sometime.

It's potentially something that simply fell through the cracks of the effort to support Qt6 (the version I think you're using).

RbnJrg · 06-03-2022, 01:30 PM

Quote:

Originally Posted by DiapDealer

This is the first I've heard of the CodeView custom colors preferences not working under Linux. I'll have to look into it this weekend sometime.

It's potentially something that simply fell through the cracks of the effort to support Qt6 (the version I think you're using).

Forget what I wrote. After changing the font for code view (now I use Liberation Mono) all worked fine. With the previous font (it was Courier New) CodeView custom colors didn't work.

KevinH · 06-03-2022, 01:30 PM

And in those CV colour preferences settings only impact the current theme (dark or light) and are actually two different sets behind the scenes. If Sigil is in dark mode when launched those colour settings will only impact dark mode. If Sigil is in Light mode when launched, those setting will only impact light mode.

So perhaps forcing dark mode on Linux is not being detected as dark mode and so those CV colour setting changes have no impact.

Just a guess...

DiapDealer · 06-03-2022, 02:05 PM

I'll take a peek. But I'm pretty sure the dark theme detection was working correctly last time I looked--especially with FORCE_SIGIL_DARKMODE_PALETTE. Some of the other "dark" system themes... maybe, but not the inherent one we created for Sigil. But all bets are off with Qt6. I don't know that I ever even tried to customize CodeView colors using Qt6.

But it sounds as if he got something working there after all.

05-31-2022, 09:51 AM	#34
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	FWIW, if you search the gcc.gnu.org bugzilla for "lto" (link time optimizer -flto) you will see a large number of freshly reported lto gcc bugs this month alone and not counting the ones in April or earlier. Not sure why they add that compiler switch for Sigil, but given it works with lto with Qt6 but not with Qt5, then it is something in Qt5 that probably triggers the gcc bug. So creating a cut-down test case will be a real problem. Perhaps just dropping the lto switch from the Sigil builds and building with Qt5 might be the safest path forward for Arch. Or using clang? That said, why is Arch the only one seeing this if the bug is in the latest gcc? Perhaps other distributions actually have the same issue. Does anyone know? Last edited by KevinH; 05-31-2022 at 10:00 AM.

06-03-2022, 06:45 AM	#36
rebski Member Posts: 17 Karma: 12 Join Date: Sep 2009 Device: SmartQ 7	I am having instant crashing problems with the update to v1.9.10 on OpenSUSE Tumbleweed, prior to that all was fine. Just wondering if I am alone? Not sure what to do except wait, no doubt it will get fixed in due course. Last edited by rebski; 06-03-2022 at 07:01 AM.

06-03-2022, 12:36 PM	#40
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Yes. FORCE_SIGIL_DARKMODE_PALETTE=1 should give Sigil the same dark theme as Windows on Linux. You can also use kvantum and/or qt6ct (or qt5ct if Sigil is built using Qt5) to choose from several different available themes (light or dark). The idea is to first defer to system/desktop theming on Linux, but allow users to force Sigil to use its inherent dark theme if that's what they wish. Last edited by DiapDealer; 06-03-2022 at 12:38 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Sigil-1.5.1 Released	DiapDealer	Sigil	27	04-15-2021 10:27 AM
Sigil-0.9.11 Released	DiapDealer	Sigil	37	02-18-2019 06:56 PM
Sigil-0.8.900 released for testing - Wait for Sigil-0.8.901	KevinH	Sigil	106	10-04-2015 10:41 AM
Sigil 0.7.0 Released	user_none	Sigil	75	03-03-2013 12:41 PM

05-30-2022, 05:17 PM	#31
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I think it's definitely a package problem. It crashes immediately for me -- with almost no output. But when I build Sigil myself (using the exact same system Qt5 version and system glibc), it runs fine. I use the bundled subprojects that we include in Sigil's source (prce2, minzip, etc) when building, so I guess it could technically be one of those system libraries that their package de-bundles but I doubt it. New Sigil maintainer over there, so I'll let their in-house bug system protocols play out a bit.

05-30-2022, 05:19 PM	#32
RbnJrg Wizard Posts: 1,542 Karma: 6613969 Join Date: Mar 2013 Location: Rosario - Santa Fe - Argentina Device: Kindle 4 NT	Many thanks Kevin, Doitsy and DiapDealer. I really don't know what is the cause of the issue with the official package from Arch; I tried with QTWEBENGINE_DISABLE_SANDBOX=1 and QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" without success. So I built Sigil with the very clear instructions by DiapDealer and now I have a fully functional Sigil 1.9.10 Thank you very much again!

06-03-2022, 11:45 AM	#38
RbnJrg Wizard Posts: 1,542 Karma: 6613969 Join Date: Mar 2013 Location: Rosario - Santa Fe - Argentina Device: Kindle 4 NT	In Windows, I use a light theme, but I have Sigil with the dark theme by setting the enviroment variable SIGIL_USES_DARK_MODE to 1. And it works fine. In Linux, I also have a light theme and I wanted to put Sigil in "dark mode" by writting in the file /etc/enviroments SIGIL_USES_DARK_MODE=1 but with no result. I also tryed writting in /etc/profile but, no case, Sigil refuses to enter in "dark mode". What am I doing wrong? Many thanks in advance.

06-03-2022, 12:15 PM	#39
BeckyEbook Guru Posts: 692 Karma: 2180740 Join Date: Jan 2017 Location: Poland Device: Misc	@RbnJrg: Try FORCE_SIGIL_DARKMODE_PALETTE

06-03-2022, 01:16 PM	#42
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	This is the first I've heard of the CodeView custom colors preferences not working under Linux. I'll have to look into it this weekend sometime. It's potentially something that simply fell through the cracks of the effort to support Qt6 (the version I think you're using).

06-03-2022, 01:30 PM	#44
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	And in those CV colour preferences settings only impact the current theme (dark or light) and are actually two different sets behind the scenes. If Sigil is in dark mode when launched those colour settings will only impact dark mode. If Sigil is in Light mode when launched, those setting will only impact light mode. So perhaps forcing dark mode on Linux is not being detected as dark mode and so those CV colour setting changes have no impact. Just a guess...

06-03-2022, 02:05 PM	#45
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'll take a peek. But I'm pretty sure the dark theme detection was working correctly last time I looked--especially with FORCE_SIGIL_DARKMODE_PALETTE. Some of the other "dark" system themes... maybe, but not the inherent one we created for Sigil. But all bets are off with Qt6. I don't know that I ever even tried to customize CodeView colors using Qt6. But it sounds as if he got something working there after all.

Advert

Advert