Hi,
Finally we can build out and load the libqt5.so successfully, but the loading
is still very slow because too many symbols are to be relocated.
Even many of these relocated symbols are inside the libqt5.so, we suppose they
should be resolved during the link time instead of loading time.
And
On Jul 23, 2012 7:51 PM, logic.cpp
logic@gmail.comjavascript:_e({}, 'cvml',
'logic@gmail.com');
wrote:
So - are you suggesting that Qt file-system monitoring facilities
should actually generate an in-memory snapshot of the necessary
directory tree(s) for platforms that need it (in
More information that from gcc the -Wl,-Bsymbolic can be used to bind
references to global symbols to the definition within the so, if any.
So what's the symbolic consideration for ARM toolchain in qt ?
Thanks,
Song
-Original Message-
From:
On Jul 23, 2012 11:49 PM, Sylvain Pointeau sylvain.point...@gmail.com
wrote:
I really like the idea of 1 signal and use the best as possible of each
OS. I am against Qt to make a snapshot of the directory because it will not
be done efficiently, means that this code, to be efficient, depends on
On terça-feira, 24 de julho de 2012 04.03.31, song.7@nokia.com wrote:
Thanks, are such undefined symbols normal ? And is there a way to fix it ?
Missing only the _ZTI ones is highly irregular. The typeinfo objects are
always emitted together with the virtual table and other objects. Since
Thanks, are such undefined symbols normal ? And is there a way to fix
it ?
Missing only the _ZTI ones is highly irregular. The typeinfo objects
are always emitted together with the virtual table and other objects.
Since the virtual tables are not missing, the only explanation I can
give is
On terça-feira, 24 de julho de 2012 01.42.20, peng-peter@nokia.com wrote:
We are now porting Qt5 (selected modules) on a low profile device
(ARM11@300MHz). All shared objects can XIP - so there is no need to load
libs from ROM to RAM. But a major problem is the loading time of an
It will only be inefficient for the few platforms that don't support the
functionality. The cost for platforms that already do provide the
functionality is zero.
Filesystem notifications are a pretty basic piece of functionality, and
having them be 100% cross platform would be a huge win for
On terça-feira, 24 de julho de 2012 09.57.48, shane.kea...@accenture.com
wrote:
Thanks, are such undefined symbols normal ? And is there a way to fix
it ?
Missing only the _ZTI ones is highly irregular. The typeinfo objects
are always emitted together with the virtual table and other
On terça-feira, 24 de julho de 2012 06.40.15, song.7@nokia.com wrote:
This paintEvent is implemented inside the analogclock.cpp, but readelf -r
analogclock shows that:
Relocation section '.rel.dyn' at offset 0x1b08 contains 72
entries:
Offset InfoTypeSym.Value Sym.
On terça-feira, 24 de julho de 2012 08.42.29, song.7@nokia.com wrote:
Thanks, but can you detail more about the ELF pre-linking ?
/sbin/prelink
Indeed, I think prelinking is the only solution for your case. Given the
statistics I posted on another email, the merging of libraries will not
On Monday 23 July 2012 23:58:16 martin.jo...@nokia.com wrote:
So maybe this should be configurable?
Perhaps. I'm wary of exposing details of the current implementation in API.
I'm not sure how this is an implementation detail. It can be as high level as
cache size in MB.
QPixmapCache has
Hello all,
We, the doc team, would like to implement a change to how we document QML types
in QDoc.
Currently, QDoc assumes things about the \qmlclass command that causes errors
or misinforms about the true nature of the QML type.
Example usage: \qmlclass Item QQuickItem
For example, we advise
Hi,
Tasks for the doc team:
-implement change in QDoc, but gracefully deprecate the \qmlclass by
giving
a warning about using \instantiates instead.
-go through the modules and change the documentation. Notify the
maintainer.
-send email to the affected maintainers.
Just to be clear: the
On terça-feira, 24 de julho de 2012 12.13.27, Thiago Macieira wrote:
QFocusHelper
This is a class defined in a .cpp, deriving from QWidget. So it has virtual
methods by way of inheritance.
But since it's in a .cpp, we have to conclude it's a compiler bug.
QAbstractUndoItem
This is a real,
Hi,
I would like to tidy up some more of the OpenGL support in Qt5. Throughout
Qt5's OpenGL support classes there are a large number of #defines copy and
pasted from upstream OpenGL/ES headers. We now have quite a significant number
of such defines in the Qt code base.
The following WIP patch
On Tuesday 24 July 2012 13:06:30 Thiago Macieira wrote:
On terça-feira, 24 de julho de 2012 12.13.27, Thiago Macieira wrote:
QFocusHelper
This is a class defined in a .cpp, deriving from QWidget. So it has virtual
methods by way of inheritance.
But since it's in a .cpp, we have to
Thanks ! Last one is: 9: 0 OBJECT WEAK DEFAULT UND
_ZTI28QNetworkConfigurationPrivate.
-Original Message-
From: development-bounces+song.7.liu=nokia@qt-project.org
[mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of
ext Thiago Macieira
On terça-feira, 24 de julho de 2012 13.02.01, song.7@nokia.com wrote:
Thanks ! Last one is: 9: 0 OBJECT WEAK DEFAULT UND
_ZTI28QNetworkConfigurationPrivate.
Virtual, inline, non-exported destructor. It's the same case as
QStaticTextUserData, except it's not exported.
Since
On terça-feira, 24 de julho de 2012 16.25.22, Olivier Goffart wrote:
On Tuesday 24 July 2012 13:06:30 Thiago Macieira wrote:
On terça-feira, 24 de julho de 2012 12.13.27, Thiago Macieira wrote:
QFocusHelper
This is a class defined in a .cpp, deriving from QWidget. So it has
virtual
On terça-feira, 24 de julho de 2012 15.17.23, Thiago Macieira wrote:
Here we have a big problem. QNetworkConfigurationPrivate is not exported, so
it can't be used from the plugins. It should be exported and its virtual
destructor should be de-inlined.
Actually, since the class is not derived
Yes, the bottleneck of the loading now is the local relocations instead of
inter-library's.
So what we want to do will be reducing the number of local relocation.
Based on my understanding, this local relocation should be caused by the
symbol inter-positioning.
And from gcc option -Bsymbolic:
On terça-feira, 24 de julho de 2012 15.17.23, Thiago Macieira wrote:
Here we have a big problem. QNetworkConfigurationPrivate is not
exported, so it can't be used from the plugins. It should be
exported
and its virtual destructor should be de-inlined.
Actually, since the class is not
On 07/24/2012 05:08 AM, ext Thiago Macieira wrote:
It looks like your system has a major issue with dynamic linking if it takes
10 seconds to load two or three libraries. Take QtGui's statistics (ok, on
Linux, but it's an indication):
libQtCore.so.5: 3953 relocations, 3658 relative (92%), 236
On terça-feira, 24 de julho de 2012 13.22.25, song.7@nokia.com wrote:
Yes, the bottleneck of the loading now is the local relocations instead of
inter-library's.
So what we want to do will be reducing the number of local relocation.
Based on my understanding, this local relocation should
On Mon, Jul 23, 2012 at 4:31 AM, lars.kn...@nokia.com wrote:
On 7/19/12 4:45 PM, ext Girish Ramakrishnan gir...@forwardbias.in
wrote:
On Thu, Jul 19, 2012 at 7:16 AM, lars.kn...@nokia.com wrote:
On 7/16/12 12:43 PM, ext Stephen Kelly stephen.ke...@kdab.com wrote:
On Sunday, July 15, 2012
On 7/23/12 1:54 PM, Stephen Chu wrote:
I was adding rows to a form layout and find that once I checked the
Buddy checkbox, the OK button became disabled:
http://i.imgur.com/j6cth.png
Is this intended? How do I set the pair to be buddies then?
This is with Creator 2.5.1 built from git pull
Hi. This is WRT fix
https://codereview.qt-project.org/#change,30222,patchset=2 for 4.8
declarative.
The changeset allows drag actions to occur with more 2D freedom, but it
steals the mouse (and prevents stealing by the parent flickable) in
order to do so. I can't think of a way to execute
On Jul 24, 2012 3:09 AM, Sylvain Pointeau sylvain.point...@gmail.com
wrote:
having them inefficient is worst than not having them.
Arguably. We have to choose from the following:
1) Make Qt only target Lion+, drop Leopard support as well as any platform
without fine grained fs notifications
2)
4) put the functionality in an add-on, which has no requirement of supporting
all platforms, and allow people who need it link to it. It can live its life
there until a decent algorithm and API has been developed, and then we can
bring it in if we want.
--
Sent from my Nokia N9
On 7/24/12
On Tue, Jul 24, 2012 at 11:59 PM, marius.storm-ol...@nokia.com wrote:
4) put the functionality in an add-on, which has no requirement of supporting
all platforms
Really? Was a community decision agreed upon about that earlier?
Perhaps I have just missed something, but as an official Qt
-Original Message-
From: ext David Faure [mailto:david.fa...@kdab.com]
On Monday 23 July 2012 23:58:16 martin.jo...@nokia.com wrote:
So maybe this should be configurable?
Perhaps. I'm wary of exposing details of the current implementation in
API.
I'm not sure how this is an
32 matches
Mail list logo
