[Qt-creator] How to produce an executable with static libraries?
Dear All, How to produce an executable with static libraries? Thanks in advance, Paul ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] How to produce an executable with static libraries?
Try this: http://www.formortals.com/build-qt-static-small-microsoft-intel-gcc-compiler/ On Sat, Apr 24, 2010 at 5:20 AM, Paul Smith phh...@gmail.com wrote: Dear All, How to produce an executable with static libraries? Thanks in advance, Paul ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator -- If you wish to make an apple pie from scratch you must first invent the universe. --Carl Sagan ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer
On 19 Apr 2010, at 17:33, Tobias Hunger wrote:
On 19.04.2010 18:02, ext Danny Price wrote:
I think the settings in the .pro file should always take priority. This
is allows for automated builds and builds outside of Creator.
I do not get your point here: Of course the pro-file gets preference.
Qmake does not know of the .user file at all, so if you run qmake
outside creator will of course completely ignore any Creator settings.
Yes but the reverse is no-longer true.
It
shouldn't be muddied up to handle Creator special-cases. That sets
a precedent.
I do not consider shadow building to be a creator special case. I use it
for all projects I work on (be it qmake based or cmake or even
autotools, if they actually support it without too much breakage) and
did so long before I started using Qt Creator in earnest. It makes
switching between different configurations of a project so much easier,
be it debug/release, different set of defines/dependencies or even
different platforms.
You should really give it a try! You are missing out if you do not.
It doesn't seem to offer anything that qmake can do with a little tweaking. In
fact, I consider it a flaw in Creator that the template projects used by the
wizards contain such basic pro files. They need a LOT of tweaking before they
can be useful.
Perhaps you could give me a concrete example where shadow builds do something
that .pro files settings cannot?
I'm not sold on the idea that Creator must turn on shadow builds by
default. If it's an issue as stated by Tobias, why not simple turn it on
in via the Project screen/pro.user file for the projects that require it
as was the case previously?
Why not simply turn it off for the projects that do not need it?
Seriously, this does not get us anywhere.
Because as I explained in my previous email to Tobias with my attached sample
project, simply turning off the settings still leaves my projects borked. I
have to manually go through the file system and trash all the make files to get
them working again. And if I check in the working project into SVN, the next
user who checks it out will have to go through the whole process again if they
neglect to uncheck the shadow build option in their newly-generated pro.user
files before hitting build.
I'm tempted to write a little script that actually goes through my projects and
cleans down the broken make files. This is clearly a failure in Creator's part
as an IDE.
What exactly is broken for you? Which of your settings are ignored by
creator?
The functionality is identical.
No, shadow building is far more flexible and I am convinced we should
offer that flexibility by default. Plus it reduces the number of clean
up issues we currently have with creator when switching configurations.
But It shouldn't override my handcrafted .pro file settings! I shouldn't have
to re-configure all my project settings every-time Nokia release a new version
of Creator and decide to turn on some new feature that breaks them.
Tobias, your statement seems to imply that the Nokia/Qt devs are also
throwing away their pro.user files to get builds working which is the
underlying issue.
I usually do not delete my .user files, but I sometimes do loose them
when running git clean in the terminal. I keep forgetting that creator
can do that nowadays (and it will leave the .user file by default;-)
If that's the case, why not fix pro.user files once
and for all? Fix the problem at source?
The .user file does what it is meant to do quite well for my use case.
You seem to have a different use case which I would really like to
understand.
I use Creator daily, both in a production environment and as a hobbyist. The
proi.user files have repeatedly proven to be very brittle and break my builds.
One issue is the fact that they cannot be used with with source control, so
every compiler setting, dependency, flag and build step has to be created
manually every-time someone does a clean checkout of the project. I know of no
other IDE that does this. It was for this reason that I gave up on the Project
screen and stated coded everything into the .pro files. To qmakes credit, it's
all worked so far. At least until I tried importing my projects into the latest
snapshot.
I've also had many issues where Creator cannot find the binaries it just built
('Permissions wrong?) or couldn't locate objects to link to resulting in
linker errors that Creator simply reported as generic makefile failures. This
often happened when a project was built independently of a session when
previously it was built as a subdir.
In ALL CASES, the problems were fixed by trashing the .pro.user files. And
there are plenty of over Creator users who will confirm this.
The point I'm making is that the flaws of the .pro.user system could previously
be worked around in the .pro file and we could happily trash the .pro.user file
whenever it
Re: [Qt-creator] printf() with Qt Creator?
Definitely an issue here. I created a C++ project and added CONFIG += console
to the pro file. The following does NOT print to the console until after main
returns (as shown with a breakpoint)
#include iostream
int main()
{
std::cout test;
return 0;
}
However if I add cout.flush() before the return, the output appears:
#include iostream
int main()
{
std::cout test;
std::cout.flush();
return 0;
}
The CONFIG += console line appears to have NO EFFECT. This must be a recent
regression because I'm sure this used to work. I've not been able to get it to
work at all with stdio.h as I think it lacks a standard function to flush the
buffer.
On 15 Apr 2010, at 08:47, Brad Hubbard wrote:
Berk Demirkır wrote:
A simple program output that prints a lot via printf don't show on
Application Output. But when i close this application output shows. Strange
issue...
Sounds like the output buffer is not being flushed.
Cheers,
Brad
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] printf() with Qt Creator?
Strange, as was expected, works for me. Could you please attach the
console output of your compiler. And give the information about your
environment.
Thank you.
On 2010/04/24, at 21:25, Danny Price wrote:
Definitely an issue here. I created a C++ project and added CONFIG
+= console to the pro file. The following does NOT print to the
console until after main returns (as shown with a breakpoint)
#include iostream
int main()
{
std::cout test;
return 0;
}
However if I add cout.flush() before the return, the output appears:
#include iostream
int main()
{
std::cout test;
std::cout.flush();
return 0;
}
The CONFIG += console line appears to have NO EFFECT. This must be a
recent regression because I'm sure this used to work. I've not been
able to get it to work at all with stdio.h as I think it lacks a
standard function to flush the buffer.
On 15 Apr 2010, at 08:47, Brad Hubbard wrote:
Berk Demirkır wrote:
A simple program output that prints a lot via printf don't show on
Application Output. But when i close this application output
shows. Strange issue...
Sounds like the output buffer is not being flushed.
Cheers,
Brad
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
--
Bruno Matos
bruno.ma...@gmail.com
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] printf() with Qt Creator?
Danny Price wrote:
Definitely an issue here. I created a C++ project and added CONFIG +=
console to the pro file. The following does NOT print to the console
until after main returns (as shown with a breakpoint)
#include iostream
int main()
{
std::cout test;
return 0;
}
This is also an issue in non-Qt apps. Just change this line:
std::cout test;
to this:
std::cout test std::endl;
On some platforms (*nix, I think) you need to do this in order to keep
the next output from overwriting the line test.
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] printf() with Qt Creator?
OSX 10.6.3 Leopard, Qt 4.6.2, Creator build 1.3.83 (rev 026237b008).
pro:
SOURCES += main.cpp
CONFIG += console
Build log:
Running build steps for project ArrayTest...
Starting: /usr/bin/make clean -w
make: Entering directory `/Users/ks/Projects/ArrayTest-build'
rm -f main.o
rm -f *~ core *.core
make: Leaving directory `/Users/ks/Projects/ArrayTest-build'
Exited with code 0.
Configuration unchanged, skipping qmake step.
Starting: /usr/bin/make -w
make: Entering directory `/Users/ks/Projects/ArrayTest-build'
g++ -c -pipe -g -gdwarf-2 -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.5
-Wall -W -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/local/Trolltech/Qt-4.6.2/mkspecs/macx-g++ -I../ArrayTest
-I/usr/local/Trolltech/Qt-4.6.2/lib/QtCore.framework/Versions/4/Headers
-I/usr/local/Trolltech/Qt-4.6.2/include/QtCore
-I/usr/local/Trolltech/Qt-4.6.2/lib/QtGui.framework/Versions/4/Headers
-I/usr/local/Trolltech/Qt-4.6.2/include/QtGui
-I/usr/local/Trolltech/Qt-4.6.2/include -I. -I../ArrayTest -I.
-F/usr/local/Trolltech/Qt-4.6.2/lib -o main.o ../ArrayTest/main.cpp
g++ -headerpad_max_install_names -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.5 -o ArrayTest.app/Contents/MacOS/ArrayTest main.o
-F/usr/local/Trolltech/Qt-4.6.2/lib -L/usr/local/Trolltech/Qt-4.6.2/lib
-framework QtGui -L/usr/local/Trolltech/Qt-4.6.2/lib
-F/usr/local/Trolltech/Qt-4.6.2/lib -framework QtCore
make: Leaving directory `/Users/ks/Projects/ArrayTest-build'
Exited with code 0.
(ArrayTest is just a dummy project I previously created for something else)
On 24 Apr 2010, at 22:21, Bruno Matos wrote:
Strange, as was expected, works for me. Could you please attach the
console output of your compiler. And give the information about your
environment.
Thank you.
On 2010/04/24, at 21:25, Danny Price wrote:
Definitely an issue here. I created a C++ project and added CONFIG
+= console to the pro file. The following does NOT print to the
console until after main returns (as shown with a breakpoint)
#include iostream
int main()
{
std::cout test;
return 0;
}
However if I add cout.flush() before the return, the output appears:
#include iostream
int main()
{
std::cout test;
std::cout.flush();
return 0;
}
The CONFIG += console line appears to have NO EFFECT. This must be a
recent regression because I'm sure this used to work. I've not been
able to get it to work at all with stdio.h as I think it lacks a
standard function to flush the buffer.
On 15 Apr 2010, at 08:47, Brad Hubbard wrote:
Berk Demirkır wrote:
A simple program output that prints a lot via printf don't show on
Application Output. But when i close this application output
shows. Strange issue...
Sounds like the output buffer is not being flushed.
Cheers,
Brad
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
--
Bruno Matos
bruno.ma...@gmail.com
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] printf() with Qt Creator?
On 24 Apr 2010, at 22:22, Robert Hairgrove wrote: This is also an issue in non-Qt apps. Just change this line: std::cout test; to this: std::cout test std::endl; On some platforms (*nix, I think) you need to do this in order to keep the next output from overwriting the line test. Thanks it now works! The CONFIG += console line appears to have no effect on OSX either way. I suppose it's really for Windows? I've not been able to get printf to work though, even with a '\n'. ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] printf() with Qt Creator?
Note that endl includes an implicit flush, so this isn't really news. Buffered I/O is buffered I/O and you should never write code that depends on buffered I/O being output before an explicit flush. By the way, IIRC, fflush(stdout) should work for stdio.h I/O. /s/ Adam On Sat, Apr 24, 2010 at 4:51 PM, Danny Price deepblue...@googlemail.com wrote: On 24 Apr 2010, at 22:22, Robert Hairgrove wrote: This is also an issue in non-Qt apps. Just change this line: std::cout test; to this: std::cout test std::endl; On some platforms (*nix, I think) you need to do this in order to keep the next output from overwriting the line test. Thanks it now works! The CONFIG += console line appears to have no effect on OSX either way. I suppose it's really for Windows? I've not been able to get printf to work though, even with a '\n'. ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
[Qt-creator] QtCreator Crash under RHEL5 (Code Syntax Related?)
Fellows:
I happened to come across a rather unusual crash of QtCreator under
RHEL5. I will try to explain the steps to reproduce the crash:
1) Go to a function implementation line, like:
int FooClass::FooFunction(int const i, int const j,
int const k, int const h)
{ ...
...
}
and break it down like so:
int FooClass::FooFunction
(int const i, int const j,
int const k, int const h)
{ ...
...
}
2) Then go to the end of the first line of arguments, erased the , and
try writing it back...
I get an instant crash each time I try to do this under RedHat 5. At
first I thought that it had something to do with the FakeVim plugin, but
no, it happens even when not using the FakeVim plugin. This appear to
indicate that for some reason the Editor can't cope with the parsing of
code written in that manner, maybe something to do with the handling of
the scope operator ::? Whatever the reason, this happens each time you
follow 1) and 2) above. I will try it under Mac tomorrow and see what
happens.
Has anyone seen this behaviour before?
Victor
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] QtCreator Crash under RHEL5 (Code Syntax Related?)
Fellows:
I don't know if this would help fix the problem, but find below some
more information on the crash. For more detailed information I would
have to recompiled QtCreator in debug mode, but the output below hints
(I hope) to the source/location of the crash, namely:
Program received signal SIGSEGV, Segmentation fault.
0x2ce72432 in CPlusPlus::BackwardsScanner::mid ()
from
/usr/local/Trolltech/Qt-4.7.0/qtcreator/lib/qtcreator/plugins/Nokia/../.
./libCPlusPlus.so.1
Victor
===
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu...
(no debugging symbols found)
(gdb) run
Starting program: /usr/local/Trolltech/Qt-4.7.0/qtcreator/bin/qtcreator.bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x2b90c93f4390 (LWP 7117)]
[New Thread 0x41df5940 (LWP 7123)]
[Thread 0x41df5940 (LWP 7123) exited]
[New Thread 0x41df5940 (LWP 7128)]
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
[New Thread 0x427fa940 (LWP 7129)]
Detaching after fork from child process 7130.
[New Thread 0x431fb940 (LWP 7135)]
[New Thread 0x43bfc940 (LWP 7136)]
Detaching after fork from child process 7137.
Detaching after fork from child process 7138.
Detaching after fork from child process 7139.
Detaching after fork from child process 7140.
Detaching after fork from child process 7141.
Detaching after fork from child process 7142.
Detaching after fork from child process 7143.
Detaching after fork from child process 7144.
[New Thread 0x445fd940 (LWP 7145)]
[New Thread 0x44ffe940 (LWP 7146)]
[New Thread 0x459ff940 (LWP 7147)]
[Thread 0x445fd940 (LWP 7145) exited]
[New Thread 0x445fd940 (LWP 7148)]
[New Thread 0x46400940 (LWP 7149)]
[Thread 0x44ffe940 (LWP 7146) exited]
[Thread 0x459ff940 (LWP 7147) exited]
[New Thread 0x459ff940 (LWP 7150)]
Detaching after fork from child process 7153.
Detaching after fork from child process 7155.
[New Thread 0x44ffe940 (LWP 7157)]
[New Thread 0x46e01940 (LWP 7158)]
[Thread 0x46400940 (LWP 7149) exited]
Program received signal SIGSEGV, Segmentation fault.
0x2ce72432 in CPlusPlus::BackwardsScanner::mid ()
from
/usr/local/Trolltech/Qt-4.7.0/qtcreator/lib/qtcreator/plugins/Nokia/../.
./libCPlusPlus.so.1
Victor Sardina wrote:
Fellows:
I happened to come across a rather unusual crash of QtCreator under
RHEL5. I will try to explain the steps to reproduce the crash:
1) Go to a function implementation line, like:
int FooClass::FooFunction(int const i, int const j,
int const k, int const h)
{ ...
...
}
and break it down like so:
int FooClass::FooFunction
(int const i, int const j,
int const k, int const h)
{ ...
...
}
2) Then go to the end of the first line of arguments, erased the , and
try writing it back...
I get an instant crash each time I try to do this under RedHat 5. At
first I thought that it had something to do with the FakeVim plugin, but
no, it happens even when not using the FakeVim plugin. This appear to
indicate that for some reason the Editor can't cope with the parsing of
code written in that manner, maybe something to do with the handling of
the scope operator ::? Whatever the reason, this happens each time you
follow 1) and 2) above. I will try it under Mac tomorrow and see what
happens.
Has anyone seen this behaviour before?
Victor
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
