Sigil Error: QtWebKitd4.dll is missing

[morp]

I intend tweeking Sigil. I started by compiling Sigil from source on Windows 7 (32 bit) using Visual Studio 2010, configured Qt for VS2010, and installed cmake. All added to system Path according individual documentation. But when I run the installed Sigil from the build, I get the following error:

"The program can't start because QtWebKit4.dll is missing from your computer. Try reinstalling the program to fix this problem"

Please, can anyone tell me what is causing this problem and how to resolve the issue or more efficient way to compile Sigil from source on Windows. I did try MinGW but it didn't work either. I used the following flag to configure the Qt for VS2010:

configure.exe -platform win32-msvc2010 -opensource -qt-zlib -no-webkit -qt-libpng -qt-libmng -qt-libtiff -no-qt3support -qt-libjpeg -nomake tools -nomake examples -nomake demos -nomake docs -nomake translations -ltcg

Thanks

[kiwidude]

Yeah the instructions for Windows are a bit incomplete/out of date.

When you build from Visual Studio, your bin\debug folder only contains the Sigil.exe and nothing else. You have to copy all the other necessary files into that folder as per the screenshot. Note that for a debug build, you need the Qt dlls (from your Qt 4.8.2 bin folder from the VS 2010 Qt install) that end with d4.dll. If you do one of the Sigil release builds, you need the Qt dlls that don't have the d in the suffix name.

The rest of the folders come from the src\Sigil\Resource_Files folder. Note the slight name difference for the dictionaries -> hunspell_dictionaries.

What tweaks do you have in mind? I am sure Dave & I would be interested to know, we have made a huge number of changes on the as yet unreleased code that you will see if you have cloned the latest Sigil source. Be good to have someone else testing them out (though bear in mind stuff that is in there currently is not guaranteed to survive the cut for the official beta release)...

[morp]

Thanks for your reply Kiwidude.

Originally Posted by kiwidude

You have to copy all the other necessary files into that folder as per the screenshot. Note that for a debug build, you need the Qt dlls (from your Qt 4.8.2 bin folder from the VS 2010 Qt install) that end with d4.dll. If you do one of the Sigil release builds, you need the Qt dlls that don't have the d in the suffix name...

I used "-no-webkit" in my configuration, why do I have to copy it again and how do you recommend I build something similar to Sigil-0.5.3-Windows-Setup.exe distribution, such that it can just install without hassle?

What tweaks do you have in mind? I am sure Dave & I would be interested to know, we have made a huge number of changes on the as yet unreleased code that you will see if you have cloned the latest Sigil source. Be good to have someone else testing them out (though bear in mind stuff that is in there currently is not guaranteed to survive the cut for the official beta release)...

I intend creating a widget that will call my CSS template and I intend having it as a tab. I'm still new to Qt and still playing around it. I don't mind testing your clone as long as they are cool and I do understand its a tweek.

[DiapDealer]

Originally Posted by morp

I used "-no-webkit" in my configuration, why do I have to copy it again and how do you recommend I build something similar to Sigil-0.5.3-Windows-Setup.exe distribution, such that it can just install without hassle?

It doesn't make a lot of sense to build/configure Qt with "-no-webkit" when Sigil requires QtWebkit.

I've found that configuring Sigil (cmake) with the "-DCMAKE_BUILD_TYPE=Release" option stops Sigil from barking about missing debug versions of the various Qt libs after building the binary Windows installer package and using it to install Sigil on a "virgin" machine.

[kiwidude]

+1 on what DiapDealer said about Webkit - the instructions for building Qt for Sigil don't say to do that so not quite sure why you did?

Having pored over the code in detail pretty much every day for the last few months I really can't recommend anyone use either the 0.5.3 codebase or indeed Qt 4.7.4 as the basis for tweaking. You are going to inherit a whole lot of bugs and pain that will distract from your own changes you want to make, stuff that had already been sorted out for 0.6.

Instead just download the official Qt 4.8.2 package built for VS 2010 and install that, no need to build Qt yourself on Windows. Then just follow the rest of the instructions for cmake to get the VS 2010 solution and what I suggested above using the latest Sigil source code. At least that way if you want to reapply your changes against a final Sigil beta/release you will be in a far better position for doing so than against 0.5.3.

Given we are still changing the latest code daily you would in a perfect world be better off waiting for an official release point. The latest checked-in code doesn't have any showstopper bugs we have found in it so far apart from an intermittent crash issue with Replace All (that may be PCRE related).

[ivanjt]

Does that mean that when the latest code is released it won't build on Qt 4.7.3? I ask because that is the latest version of Qt that we have on OS/2.

Since the only version of Sigil we have for OS/2 is 0.2.0 I was going to try and learn how to build it and so save having to start a VM with windows just to do some editing. Now it looks as if I can forget that idea.

[meme]

Correct - it won't build on less than 4.8.0.

[DiapDealer]

Originally Posted by meme

Correct - it won't build on less than 4.8.0.

Which means manually installing concurrent versions of Qt and/or custom compiling Qt on anything other than the very latest versions of Ubuntu. Ugh. I guess I better get busy so I have a build environment prepared.

[morp]

Originally Posted by DiapDealer

I've found that configuring Sigil (cmake) with the "-DCMAKE_BUILD_TYPE=Release" option stops Sigil from barking about missing debug versions of the various Qt libs after building the binary Windows installer package and using it to install Sigil on a "virgin" machine.

Please, can you give details of what you did to achieve this because the only thing that appear to solve the Qt libs problem at my end is Kiwidude's suggestion of manually copying the files to the installed directory. I tried "cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 10" " but it didn't work.
I don't wish to manually copy the Qt libs but want to build binary Windows installer package with vs2010 which would install and run on a "virgin" machine without asking for Qt lib.

[DiapDealer]

Originally Posted by morp

Please, can you give details of what you did to achieve this because the only thing that appear to solve the Qt libs problem at my end is Kiwidude's suggestion of manually copying the files to the installed directory. I tried "cmake -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 10" " but it didn't work.
I don't wish to manually copy the Qt libs but want to build binary Windows installer package with vs2010 which would install and run on a "virgin" machine without asking for Qt lib.

I've never used the Visual Studio method on Windows... only the Windows SDK (nmake) method, but it shouldn't be that much different. If you're trying to create the Sigil installer package, I assume you know that you have to have Inno Setup installed and on the system path (described in the General Notes section of the Sigil "Running form Source" instructions).

cmake -G "Visual Studio 10" -DCMAKE_BUILD_TYPE=Release /path/to/sigil/code

will create/prep the Visual Studio projects. The default build will simply create the sigil.exe. You need to build the makeinstaller project if you want to create the installer program that includes all the necessary Qt libraries, ckeditor, dictionaries, etc...

I'd also seriously consider using the pre-built Qt libraries for Visual Studio 10 (4.8.2) instead of configuring/compiling your own custom Qt. It's just not necessary to build your own Qt and it might actually cause issues if you don't do it "just right" (plus it takes for-friggin-ever to compile each time—when you inevitably find out you didn't do it right the first time).

Make sure you start from scratch: fresh downloaded and/or extracted source package ... new/empty build directory before running cmake.