[Webkit-unassigned] [Bug 30476] [Qt] [Symbian] Set the capability and memory required to run QtWebKit for Symbian

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Oct 18 16:29:18 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=30476





--- Comment #3 from Norbert Leser <norbert.leser at nokia.com>  2009-10-18 16:29:18 PDT ---
Thanks, for working on a cleanup.

- Removing EPOCALLOWDLLDATA from all executables makes sense.

- You are right, it appears that EPOCSTACKSIZE is set by qmake to the max value
(0x14000) already, and it would be redundant. The problem though is that it may
not be guaranteed that all qmake versions will set that value. If not set, the
symbian's build system falls back to the default, which is way lower than
needed. It might be safer to keep the definition in all exe's .pro files, even
if redundant.

- Janne is right that the basic capabilities needed are "ReadUserData
WriteUserData  NetworkServices". We should set these explicitly for all
executables under WebKit/qt, instead of CAP_APPLICATION (I also saw that this
macro is not available on public SDKs).

- The problem with the previous one is that you set it in WebKit.pri, which is
also processed by WebCore.pro. QtWebKit.dll, however, should have the max set
of capabilities that calling processes may require. Per convention, for shared
libraries that are used by a variety of apps, it is "All -Tcb". Otherwise, we
run into the problem that apps which require certain capabilities outside the
minimally needed ones cannot load the dll (the side-effect of the weird
capabilities model in symbian). We could add the missing capabilities in
WebCore.pro (I think), but that doesn't appear to be clean. Thus, I'd suggest
to keep TARGET.CAPABILITY definitions in the respective .pro files of the
executables (QtLauncher, QVGLauncher, all tst_*).

- This patch only addresses WebKit.pri but I assume that your intention was to
also cleanup the respective .pro files as well, once we have an understand what
goes where.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list