Yes linking may impact handling cross module exceptions. So it is plausible I think.
Either way ...
I have now pushed a reordering to the LoadFile routine to MainWindow in Sigil master to test the hypothesis of QEvents being processed out of order on initial startup when the error dialog is shown.
If BeckyEbook tests this change and it does not help, I am going to revert all of these changes then go and prevent the damn exception from being thrown at all in ImportEPUB.cpp to prevent the whole strange sequence of events.
I have already written the code to do that and can push it tomorrow once BeckyEbook reports on her testing of this reordered version.
If it does turn out to be a linking issue, then preventing the exception from being thrown in the first place makes sense as well.
Quote:
Originally Posted by DiapDealer
I don't add anything like that when building Qt or Sigil. Not to say something like that is not introduced somewhere--just that I'm not knowingly doing it.
One other thing I never thought of is that those building their own Sigil are very likely using my Qt6.7.2 built for GitHub CI. It's not built with link time optimizations (so as to be compatible with any version of VS2022 installed on Github's runner images [or any versions users may have installed]). Whereas I'm using a version built with link time optimizations for releases and for my own Sigil development. I've not made that Qt build available publicly.
When Qt is built with link time code generation enabled, then Sigil MUST be built with the exact same VS toolchain version. Perhaps that's the difference.
I guess I can check pretty easily by building Sigil with my CI version of Qt6.7.2
|