| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hybrid allocator introduced a new export to qtcore.dll and made
all apps link to it when they linked with the corresponding qtmain.lib.
However, this made all apps depend on this new export, and since that
export is not present in early 4.7.x release, these apps would not run
with the Qt DLLs from those releases, which breaks Qt's compatibility
guarantees for patch releases. This change makes apps compatible with
all 4.7.x releases again.
For export frozen Qt builds (the sort that should be compatible across
all 4.7.x releases), qtmain.lib no longer forces a static import link
to qt_symbian_SetupThreadHeap(). Instead it dynamically loads
qtcore.dll, looks up qt_symbian_SetupThreadHeap(), and calls it if
present. If the function is not present, or on emulator builds where we
know that qtcore will use the system allocator creation function, we
call the system allocator creation function.
For export unfrozen builds, there is no compatibility between builds or
releases, so we do use a static import link to
qt_symbian_SetupThreadHeap(), as we have to use the qtcore dll we have
built with it anyway.
This has been tested as follows:
S60 3.1 SDK, def files not frozen. App compiled against latest code
runs on the corresponding DLLs, and does not start with 4.7.0, which
is what we expect.
S60 3.2 SDK, def files frozen. App compiled against latest code runs
on the corresponding DLLs with the new allocator, and runs on 4.7.0
DLLs with the old allocator. Which demonstrates compatibility.
S60 5.0 SDK, def files not frozen, debug build. Same result as for
the 3.1 SDK, which demonstrates debug build working too (all other
tests are release build tests).
S60 5.0 SDK, def files frozen, debug build. Same result as on S60 3.2
SDK, which demonstrates debug build working with def files.
Symbian^3 SDK, def files frozen. Same result as on S60 3.2 SDK,
demonstrating Symbian^3 compatibility.
Symbian^4, code and tests compile and does not affect running.
*** This change is only required for 4.7. It is not needed for 4.8+ ***
*** If this change appears in 4.8+, it can be reverted. ***
Task-number: QT-4080
Reviewed-by: Shane Kearns
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New export in corelib that is called from the qtmain wrapper to setup
the thread heap. This allows 7k of code to be shared, and makes it easier
to disable or upgrade the allocator in future releases
Task-number: QTBUG-4895
Enable new allocator by default
Rename of headers as _p.h to avoid syncqt adding them to applications
move inline functions from .inl -> .h, document & rename macros
remove #if 0 from the dla header, implement getpagesize properly
squashed after sanitisation
Task-number: QT-3967
Reviewed-by: mread
|
|
|
|
|
| |
Task: QTBUG-10680
RevBy: Trust me
|
|
|
|
|
|
|
|
|
| |
MMP_RULES_DONT_EXPORT_ALL_CLASS_IMPEDIMENTA must not be included in
s60main build, otherwise some symbols will not be relocatable when
linked against from gcce build.
Task-number: QTBUG-11804
Reviewed-by: Alessandro Portale
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
mkspecs/common/symbian/symbian.conf
qmake/generators/makefile.cpp
qmake/generators/symbian/symmake.cpp
src/3rdparty/webkit/WebCore/WebCore.pro
Conflict resolution was heavily based on manual application of commit
9cc4ae77a73bd28ff495f36f26dd87c78b76b976.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When building for ARMV6 with abld toolchain in Symbian, qtmain.lib
ends up missing some symbols that are required to link it against
GCCE apps. This happens because --dllimport_runtime compiler
option is missing in ARMV6 builds of qtmain.lib.
Task-number: QTBUG-7952
Reviewed-by: axis
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
It's more appropriate to have it in QtGui after the framework classes
were moved there.
This also means that the rsgfix needed earlier is not necessary
anymore, since QtGui is not a static library.
RevBy: Janne Anttila
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way we avoid having a lot of code in a static (and
unmaintainable) library. The s60main static library now currently has
only one task: to call main().
To move the initialization into QtGui also meant a change in how the
S60 framework is created, because we can no longer use the trick
where we create and start the the S60 event loop and then have the
framework call us back to start main(). The initialization now
follows the creation and destruction of QApplication, which is a lot
more in line with how other platforms do it.
Since S60 doesn't support creating the environment, and *then*
starting it (both are executed by the same call), we had to open up
the S60 framework construction classes and just mirror what they do.
This means that after QApplication construction is done, the S60
framework is initialized, but nothing will run yet and control will
return to main(), where the user can start the event loop himself.
One of the quirks of this approach is that the construction of the
S60 framework makes a new cleanup stack. This means that any active
traps will not be active anymore, and leaving without setting a new
trap will most likely panic. This shouldn't be a problem for us,
since Qt is never supposed to leave, but it means that if anyone uses
the cleanup stack without setting a new trap, they will receive a
panic.
It was considered to add a trap mark in QApplication construction and
then removing it on destruction, but it was dropped because leaving
from main() is still undefined (even if the old cleanup stack would
be restored in the destructor, we wouldn't be able to stop the
exception from unwinding the stack, and the cleanup stack would then
be unbalanced).
RevBy: Jason Barron
RevBy: Janne Anttila
AutoTest: QWidget passed with same failure count
|
|
|
|
|
|
|
|
| |
Even though the static app is public in the sense that it is included
in every program, the headers it contains are not.
RevBy: Jason Barron
AutoTest: tst_headers passed
|
| |
|
|
|