Bug 19109 – WebKitGtk fails to build from source: "SQLiteStatement has not been declared"

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[nousername]

Building on Gentoo Linux, AMD64, CFLAGS="-march=athlon64 -O2"

webkitgtk was configured with:
+pango backend
+svg-experimental
+xslt
+curl backend
-* everything else disabled (including the database), or left as defaults

Error snippet:

[. . .]
WebCore/loader/appcache/ApplicationCacheStorage.h:72: error: 'SQLiteStatement' has not been declared
mv -f WebCore/platform/network/curl/.deps/libWebCore_la-ResourceHandleManager.Tpo WebCore/platform/network/curl/.deps/libWebCore_la-ResourceHandleManager.Plo
make[1]: *** [WebCore/loader/appcache/libWebCore_la-ApplicationCacheGroup.lo] Error 1
make[1]: Leaving directory `/var/tmp/portage/net-libs/webkitgtk-33561/work/WebKit-r33561'
make: *** [all] Error 2

Removing this line from the code and recompiling just results in many other similar errors for the SQLite stuff -- clearly much of the code is expecting something that just doesn't exist.

It's a wonder this webkit nightly builds for *anyone*. This is a complete blocker; I can't even compile the darned thing, much less use it with Midori.

[Mark Rowe (bdash)]

> It's a wonder this webkit nightly builds for *anyone*. This is a complete
> blocker; I can't even compile the darned thing, much less use it with Midori.

You'll probably have much better luck with the default configure flags rather than disabling random features.  We currently only have automated build testing for the default configuration of the Gtk port -- testing every conceivable configuration with each revision would be very time consuming.

[nousername]

(In reply to comment #1)
> > It's a wonder this webkit nightly builds for *anyone*. This is a complete
> > blocker; I can't even compile the darned thing, much less use it with Midori.
> 
> You'll probably have much better luck with the default configure flags rather
> than disabling random features.  We currently only have automated build testing
> for the default configuration of the Gtk port -- testing every conceivable
> configuration with each revision would be very time consuming.

. . . except I'm not "disabling random features." I didn't want database support, because I see no need to bloat my particular webkitgtk. So I explicitly disabled it, and left everything else at the defaults ('cept for using pango for fonts, rather than the default).

Sure, maybe testing with "every possible combination" of flags would be time consuming, but in this case it's irrelevant -- there's simply lots of missing code, regardless of flags chosen.

I still consider this a "blocker", because if webkitgtk can't be built without database support, then it shouldn't be a configurable option. One less way for packagers and distributors to hurt themselves and their users.

[Alp Toker]

Josh,

I've fixed non-database builds in trunk. If you disable local web app support, DOM storage, database and icon database sqlite will not be used. If you select an invalid configuration, the configure script will warn you and won't allow you to proceed. If you still have issues, please re-open this bug.