On sábado, 15 de setembro de 2012 13.12.22, Loaden wrote:
> See Qt5CoreConfigExtras.cmake
>
> > LN34: list(APPEND Qt5Core_INCLUDE_DIRS
> > "${_qt5_corelib_install_prefix}/mkspecs/default")
>
> I thought it should be:
> list(APPEND Qt5Core_INCLUDE_DIRS
> "${_qt5_corelib_install_prefix}/mkspecs/win32
On sexta-feira, 14 de setembro de 2012 21.59.45, Geoffrey Gowey wrote:
> line 126: Error: Formal argument 3 of type unsigned* in call to accept(int,
> sockaddr*, unsigned*) is being passed int*.
Ugh... socklen_t again...
Please see mkspecs/solaris-cc/qplatformdefs.h and check why QT_SOCKLEN_T was
On sábado, 15 de setembro de 2012 01.54.29, Laszlo Papp wrote:
> > I disagree and I think we ought to think more about them. Especially
> > since,
> > without my fix, they had to patch Qt.
>
> This is not what you tried to achieve with the tarball distribution even
> when packager(s) asked explicit
See Qt5CoreConfigExtras.cmake
> LN34: list(APPEND Qt5Core_INCLUDE_DIRS
> "${_qt5_corelib_install_prefix}/mkspecs/default")
>
I thought it should be:
list(APPEND Qt5Core_INCLUDE_DIRS
"${_qt5_corelib_install_prefix}/mkspecs/win32-msvc2010")
Or, just remove it.
I don't know why we need this path f
On 14/09/2012 10:55 PM, kai.koe...@nokia.com wrote:
>>> That's interesting. So the linking of designer_components with the
>>> precompiled header works for you?
>> It turns out so ..
>> Or, perhaps, the matter is that you used 32-bit MinGW for
>> crosscompiling for 64-bit.
> No, actually the error
On 14/09/2012 7:55 PM, niXman wrote:
> Today, reading this(qt-project.org/wiki/MinGW-64-bit) note, I paid
> attention to the fact that it refers to the need to edit qmake.conf
> Qt5 for building 64-bit.
> But yesterday, I have built Qt5 for 64-bit successfully without
> changing qmake.conf.
> Tell
Hello all,
I'm trying to compile Qt (pulled down via git) on Solaris 11 using Oracle
Solaris Studio 12.3 and am receiving the following error:
/opt/solarisstudio12.3/bin/CC -c -O2 -mt -KPIC -DQT_SHARED
-DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -
>
> I disagree and I think we ought to think more about them. Especially since,
> without my fix, they had to patch Qt.
>
This is not what you tried to achieve with the tarball distribution even
when packager(s) asked explicitely so. The packagers were not considered as
said they should all solve
On sexta-feira, 14 de setembro de 2012 18.27.31, Oswald Buddenhagen wrote:
> well, i disagree.
> if you want backtraces, not stripping some minor symbol tables doesn't
> buy you much; you need to force proper debug info on anyway.
> i also don't think that "end users" never build qt themselves. all
On Fri, Sep 14, 2012 at 04:31:52PM +0200, ext Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 16.25.46, Oswald Buddenhagen wrote:
> > > I made it default to no-stripping.
> >
> > which i don't understand ...
>
> Simon's email:
>
> "I think that our default configure and make rule
On Fri, September 14, 2012 04:35:47 PM Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 16.21.44, Thomas Senyk wrote:
> > On Fri, September 14, 2012 04:08:57 PM Thiago Macieira wrote:
> > > I made it default to no-stripping.
> >
> > Why? Shouldn't stripping be the default?
>
> I do
On sexta-feira, 14 de setembro de 2012 16.33.14, Robin Burchell wrote:
> On Fri, Sep 14, 2012 at 4:21 PM, Thomas Senyk
>
> wrote:
> > A argument for stripping as default:
> > A lot of people don't know what's the right thing to do in most cases ...
> > so
> The people building Qt generally know wh
On sexta-feira, 14 de setembro de 2012 16.21.44, Thomas Senyk wrote:
> On Fri, September 14, 2012 04:08:57 PM Thiago Macieira wrote:
> > I made it default to no-stripping.
>
> Why? Shouldn't stripping be the default?
I don't think it should, neither does Simon. But Lars, Ossi and you think it
shou
On Fri, Sep 14, 2012 at 4:21 PM, Thomas Senyk
wrote:
> A argument for stripping as default:
> A lot of people don't know what's the right thing to do in most cases ... so
The people building Qt generally know what they're doing. Either
they're working on Qt (or things using Qt) - either case of w
On sexta-feira, 14 de setembro de 2012 16.25.46, Oswald Buddenhagen wrote:
> > I made it default to no-stripping.
>
> which i don't understand ...
Simon's email:
"I think that our default configure and make rules should be tailored towards
developers deliberately building Qt from source, so IMHO
On Fri, September 14, 2012 04:08:57 PM Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 14.56.08, Oswald Buddenhagen wrote:
> > > If it is, I'll instead add an option to configure that toggles the
> > > "nostrip" option in CONFIG.
> >
> > that would be preferable.
>
> Commit updat
On Fri, Sep 14, 2012 at 04:08:57PM +0200, ext Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 14.56.08, Oswald Buddenhagen wrote:
> > > If it is, I'll instead add an option to configure that toggles the
> > > "nostrip" option in CONFIG.
> > >
> > >
> >
> > that would be preferabl
On Fri, Sep 14, 2012 at 2:49 AM, Samuel Rødal wrote:
> On 09/12/2012 06:52 AM, ext Chris Meyer wrote:
>> My software makes use of accelerated drawing using the techniques with
>> QGraphicsView and QGraphicsScene shown in this article:
>>
>> http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
>>
>> U
On sexta-feira, 14 de setembro de 2012 14.56.08, Oswald Buddenhagen wrote:
> > If it is, I'll instead add an option to configure that toggles the
> > "nostrip" option in CONFIG.
> >
> >
>
> that would be preferable.
Commit updated.
I made it default to no-stripping.
The option does not apply to
On Fri, Sep 14, 2012 at 2:49 AM, Samuel Rødal wrote:
> On 09/12/2012 06:52 AM, ext Chris Meyer wrote:
>> My software makes use of accelerated drawing using the techniques with
>> QGraphicsView and QGraphicsScene shown in this article:
>>
>> http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
>>
>> U
2012/9/14 kai.koehne:
> No, actually the error only appeared when I was using the native 64 bit
> toolchain.
I have the possibility to increase the stack size for cc1plus.exe
during the building MinGW.
I just need to know what size of stack is needed...
--
Regards,
niXman
On Fri, Sep 14, 2012 at 10:05:03AM +0200, ext Thiago Macieira wrote:
> On sexta-feira, 14 de setembro de 2012 05.15.42, simon.hausm...@nokia.com
> wrote:
> > I think in automake this is usually solved by make install not stripping and
> > then there being also a "make install-strip" target that in
>> That's interesting. So the linking of designer_components with the
>> precompiled header works for you?
> It turns out so ..
>Or, perhaps, the matter is that you used 32-bit MinGW for
>crosscompiling for 64-bit.
No, actually the error only appeared when I was using the native 64 bit
toolchain
2012/9/14 kai.koehne:
> That's interesting. So the linking of designer_components with the
> precompiled header works for you?
It turns out so ..
Or, perhaps, the matter is that you used 32-bit MinGW for
crosscompiling for 64-bit.
> Which exact sha of qttools are you using?
fe4595462835acd9304
Hi Lars,
with everyting that has been happening recently around Qt I have not had a
chance to follow up on the QtSerialPort integration. Is there still a
chance that this could make it into Qt5?
Laszlo
http://qt.gitorious.org/qtplayground/qtserialport
http://lists.qt-project.org/pipermail/develo
If I try to build Qt5 with included zlib I got errors on the begin of
build. Build log here http://tny.cz/73e00ff0
2012/9/14 Алексей Павлов :
> Another problem with building WebKit. Why during building calling MAKE
> instead of MINGW32-MAKE.
> Error below:
>
> cd qtwebkit && set
> "WEBKITOUTPUTDI
> I edited this note.
>
Thanks. The qmake.conf changes were from an earlier attempt where I tried to
use the crosscompiler (32 bit gcc, 64 bit target). I only later on discovered
that there are two mingw-builds packages, one 64 bit and one 32 bit.
> About segfolt when building designer I do lea
I edited this note.
About segfolt when building designer I do leave, even though I have
not faced with this error.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuild
Another problem with building WebKit. Why during building calling MAKE
instead of MINGW32-MAKE.
Error below:
cd qtwebkit && set
"WEBKITOUTPUTDIR=C:/SDK/srcs/qt5/qtwebkit/WebKitBuild" && set
"PATH=C:/SDK/srcs/qt5/gnuwin32/bin;%PATH%" && perl
C:/SDK/srcs/qt5\qtwebkit\Tools\Scripts\build-webkit --qt
2012/9/14 Laszlo Papp:
> "Wiki menu" box under the ratings on the right side.
Yes, I see.
Thank you!
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
_
>
> I am registered and logged in, but I don't see any 'Edit'/'Fix' button.
>
"Wiki menu" box under the ratings on the right side.
Laszlo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On sexta-feira, 14 de setembro de 2012 13.33.13, Алексей Павлов wrote:
> I wrote earlier
> For Thiago:
> qtbase/mkspecs/qmodule.pri listing:
>
> #paths
> QT_BUILD_TREE = C:/SDK/srcs/qt5/qtbase
> QT_SOURCE_TREE = C:/SDK/srcs/qt5/qtbase
> QT_BUILD_PARTS += libs tools
>
> #Qt for Windows CE c-runti
2012/9/14 Laszlo Papp:
> If you register, you can also do that yourself.
Hmm...
I am registered and logged in, but I don't see any 'Edit'/'Fix' button.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
htt
On Fri, Sep 14, 2012 at 11:12 AM, niXman wrote:
> 2012/9/14 André Somers:
>
> > Perhaps it is outdated?
>
> Maybe...
> But I have no rights to edit this note.
> Somebody can correct this note?
>
If you register, you can also do that yourself.
Laszlo
_
14.09.2012, 14:12, "niXman" :
> 2012/9/14 André Somers:
>
>> Perhaps it is outdated?
>
> Maybe...
> But I have no rights to edit this note.
> Somebody can correct this note?
AFAIK all you need is to register.
--
Regards,
Konstantin
___
Development m
2012/9/14 André Somers:
> Perhaps it is outdated?
Maybe...
But I have no rights to edit this note.
Somebody can correct this note?
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/p
Op 14-9-2012 11:55, niXman schreef:
> Hello,
>
> Today, reading this(qt-project.org/wiki/MinGW-64-bit) note, I paid
> attention to the fact that it refers to the need to edit qmake.conf
> Qt5 for building 64-bit.
> But yesterday, I have built Qt5 for 64-bit successfully without
> changing qmake.con
Hello,
Today, reading this(qt-project.org/wiki/MinGW-64-bit) note, I paid
attention to the fact that it refers to the need to edit qmake.conf
Qt5 for building 64-bit.
But yesterday, I have built Qt5 for 64-bit successfully without
changing qmake.conf.
Tell me please, why in the wiki is said that i
On 09/12/2012 06:52 AM, ext Chris Meyer wrote:
> My software makes use of accelerated drawing using the techniques with
> QGraphicsView and QGraphicsScene shown in this article:
>
> http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
>
> Unfortunately things don't work smoothly under Qt 5.0.
>
> I
I wrote earlier
For Thiago:
qtbase/mkspecs/qmodule.pri listing:
#paths
QT_BUILD_TREE = C:/SDK/srcs/qt5/qtbase
QT_SOURCE_TREE = C:/SDK/srcs/qt5/qtbase
QT_BUILD_PARTS += libs tools
#Qt for Windows CE c-runtime deployment
QT_CE_C_RUNTIME = no
CONFIG += create_prl link_prl sse2 sse3 ssse3 sse4_1 s
On sexta-feira, 14 de setembro de 2012 13.12.04, Алексей Павлов wrote:
> The configuration program correctly parses the parameters ( see
> configure log https://gist.github.com/3720368 ), but not all modules
> receive them when building. QtSvg, qtimageformats, webkit not
> including paths from LIB
Just for the record: thanks to Simon for bringing this topic up again. We
will soon have a fix for this in the Qt Project to build for such
situations out of the box.
https://codereview.qt-project.org/#change,34779
Laszlo
___
Development mailing list
De
2012/9/13 Алексей Павлов:
> But zlib.h present in c:\sdk\ported64\include. Why configure script not add
> INCLUDE and LIB to include paths and libs paths of svg module?
> Build log: http://tny.cz/b3ea0a8b
I faced with the same problem.
After manually correction of makefiles, Qt5 nevertheless was
Hi Kai,
On 14/09/2012 6:45 PM, kai.koe...@nokia.com wrote:
>>> From: development-bounces+kai.koehne=nokia@qt-project.org
>>> [development-bounces+kai.koehne=nokia@qt-project.org] on behalf of ext
>>> Jonathan Liu [net...@gmail.com]
>> GCC uses CPATH with paths separated by colons instead
The configuration program correctly parses the parameters ( see
configure log https://gist.github.com/3720368 ), but not all modules
receive them when building. QtSvg, qtimageformats, webkit not
including paths from LIB and INCLUDE.
2012/9/14 Алексей Павлов :
> If I remember correctly that the e
If I remember correctly that the environment variables LIB and INCLUDE
parses Qt configure program (see
qtbase/tools/configure/cofigureapp.cpp)
2012/9/14 :
>>> From: development-bounces+kai.koehne=nokia@qt-project.org
>>> [development-bounces+kai.koehne=nokia@qt-project.org] on behalf of
>> From: development-bounces+kai.koehne=nokia@qt-project.org
>> [development-bounces+kai.koehne=nokia@qt-project.org] on behalf of ext
>> Jonathan Liu [net...@gmail.com]
>
> GCC uses CPATH with paths separated by colons instead of INCLUDE.
> GCC uses LIBRARY_PATH with paths separated by c
Hello Lorn,
> Because printing is a common and basic thing to want to add to applications.
> Getting info and notifications about cellId changes is more of a fringe use
> case.
Yes, it is, clear. But then why not add ScannerSupport? After all, this is the
same as the printing support. :)
For
On sexta-feira, 14 de setembro de 2012 05.15.42, simon.hausm...@nokia.com
wrote:
> I think in automake this is usually solved by make install not stripping and
> then there being also a "make install-strip" target that installs and
> strips.
cmake also produces a "install/strip" target. But I didn
I have tested 4.8.3 on LinuxMint12 x86 and Debian6 x64 for my application,
it reports segment fault on starting up. I'm not quite sure if it is Qt's
issue or my application's since my application works well yesterday when it
was built against Qt 4.8.2 on both the platform I mentioned above.
I will
Fine for me. I mainly wanted to make sure we understand what we're targeting
with the default configuration. But we at least need some ways in the build
system to strip or separate the debug info.
Cheers,
Lars
On Sep 14, 2012, at 7:15 AM, ext simon.hausm...@nokia.com
wrote:
> I think that o
Hi all,
There seems to be something wrong with Qt 4.8.3 mingw package.
It's not completely broken but we will make new package available asap.
Br,
Akseli
> -Original Message-
> From: development-bounces+akseli.salovaara=digia@qt-project.org
> [mailto:development-bounces+akseli.salova
I upload full configure.log and build.log to the webkit. Where I have
errors I add many empty lines and wrote some comments. Plese look at
them: https://gist.github.com/3720368
2012/9/13 Алексей Павлов
>
> For Thiago:
> mkspecs/qmodule.pri listing:
> #paths
> QT_BUILD_TREE = C:/SDK/srcs/qt5/qt
53 matches
Mail list logo
