| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Removed UNPAGED workaround from QtCore and QtSql on OS releases where
data paging is supported. Depends on new macro being defined in the OS
builds (SYMBIAN_DLL_DATA_EXPORTS_SUPPORTED) to allow us to detect this.
Data exports are supported in all S^3 builds after early 2009, however,
this macro is only added recently (and thus isn't defined in, eg.
Symbian Foundation PDKs (v3.0.4), or current releases (v0.9) of the S^3
SDK from Nokia). Thus building Qt against these older S^3 builds will
still result in QtCore and QtSql being unpaged.
Also, remove PAGED keyword from all Qt-based software. This changes the
code paging field in the Symbian (E32Image) header from "paged" to
"default". Thus it is left to the configuration of the particular
device whether paging is used for the binary or not. All devices that
support code paging should have it turned on (the value is stored in
the HAL, so can be checked using eg. fshell); data paging may or may
not be turned on depending on the device characteristics. Leaving both
code and data paging as "default" means that any limitations in the
device (eg. around flash wear) can be controlled by that device by
disabling the appropriate types of paging.
This change also leaves the way open to deprecated PAGED as a keyword
in the Symbian build systems, so you can only opt out of paging. This
makes more sense, as the default for code paging will be on, the
default for data paging will be on if the device can handle it, and
binaries should only be opting out of paging if they have some specific
real-time requirements that paging inhibits.
Task-number: QT-3503
Task-number: QTBUG-13931
Reviewed-by: Shane Kearns
|