Hi there,
I've just build qt5 from git (5.5 branch, commit cdc3bf5) and I'm having
problems running some qt3d examples.
I've run *all* examples and only a few don't work:
- assimp, multiviewport: window content is black
- gltf: window content is never drawn
Don't know if it's related, but the f
> I can confirm that qmake indeed works as expected outside the Qt tree. This
> is because it does not include qmodule.pri at all.
Oh, and it is not something in the qmake source code that imposes an Xcode
compiler. It happens in mkspecs/features/mac/sdk.prf , which has an equivalent
to the sec
On Monday March 23 2015 14:03:28 Thiago Macieira wrote:
> Yes.
>
> That was removed for Qt 5.4.0 because, as you can see, it doesn't work. I
> added it for Qt 4.2, one of my first few contributions and not my cleanest
> code
Heh, hard to see all implications of changes to a complex system
On Monday 23 March 2015 22:03:13 René J.V. Bertin wrote:
> - the reason the compiler settings from the mkspec are ignored is because
> qmodule.pri contains QMAKE_CC and QMAKE_CXX definitions. I don't know why
> those variables get set in there; are they taken from the CC and CXX env.
> variables (t
On Monday March 23 2015 22:03:13 René J.V. Bertin wrote:
> I can confirm that qmake indeed works as expected outside the Qt tree. This
> is because it does not include qmodule.pri at all.
Of course that also means that I end up with the Xcode clang compilers in my
Makefiles, on OS X 10.6.8 unle
I changed the subject for this particular issue
> Then please use a more standard module. Please use qtsvg for this testing.
> This removes a very complicated variable (the qtwebengine buildsystem).
This did help, but even more so using qmake's -d flag.
So my observations was that the *install
On Monday March 23 2015 11:10:06 Thiago Macieira wrote:
> On Monday 23 March 2015 18:42:01 René J.V. Bertin wrote:
> > On Monday March 23 2015 09:33:30 Thiago Macieira wrote:
> > > Ok. What is the target that was being built? The very first thing? That
> > > would be libQtBootstrap.a.
> >
> > Doe
On Monday 23 March 2015 18:42:01 René J.V. Bertin wrote:
> On Monday March 23 2015 09:33:30 Thiago Macieira wrote:
> > Ok. What is the target that was being built? The very first thing? That
> > would be libQtBootstrap.a.
>
> Does it matter what target was being built?
Are you sure it doesn't?
On Monday March 23 2015 09:33:30 Thiago Macieira wrote:
> Ok. What is the target that was being built? The very first thing? That would
> be libQtBootstrap.a.
Does it matter what target was being built? As I said in my initial message,
Apple gcc-4.2 gets quite far, and then fails. I didn't reco
Hi,
bad news because is a platformin less, i don't understand BB (their plan).
Nicola
> Hello,
>
> After discussing this with Bernd, who maintains the QNX platform together
> with
> myself, we have decided to mark the BlackBerry 10 platform unsupported.
>
> According to BlackBerry, th
Hello,
After discussing this with Bernd, who maintains the QNX platform together with
myself, we have decided to mark the BlackBerry 10 platform unsupported.
According to BlackBerry, they are still committed to Qt4 releases, but have no
plans for Qt5. With that in mind, and given the fact that we
On Monday 23 March 2015 16:00:06 René J.V. Bertin wrote:
> >Which part of a Qt build? The build of:
> > - qmake
> > - a host library or of libQtBootstrap.a
> > - a target library
>
> What's that distinction between a host and a target library?
The compiler it uses. They're different if you're cro
On Monday March 23 2015 06:53:19 Thiago Macieira wrote:
>> Just to be clear: *my* point is that on OS X those variables are basically
>> ignored during a Qt build.
>
>Which part of a Qt build? The build of:
> - qmake
> - a host library or of libQtBootstrap.a
> - a target library
What's that disti
On Sunday 22. March 2015 23.19.15 Thiago Macieira wrote:
> Anyone?
>
> This is still happening.
>
> If we don't know how to fix this, I propose we make the iOS builds
> force-pass all tests.
We haven't found the real bug yet, but we've found the change that revealed
the change, and it's been re
On Monday 23 March 2015 08:55:36 Stephen Kelly wrote:
> Thiago Macieira wrote:
> > Anything I missed? Opinions?
>
> As far as I know, qmake `CONFIG += c++11` causes
>
> -std=c++11
>
> or similar to be used on compile and link lines. For the sake of user code,
> you might want to use
>
> -std=
On Monday 23 March 2015 10:08:02 René J.V. Bertin wrote:
> On Sunday March 22 2015 23:18:17 Thiago Macieira wrote:
> >The point is that we extract QMAKE_CC and QMAKE_CXX from the mkspec so that
> >we can build qmake.
>
> Just to be clear: *my* point is that on OS X those variables are basically
>
Hi,
I'm not familiar with the exact error message you're mentioning but the easiest
way to get around "No architectures to compile for" is to set archs to the
exact same as valid archs. You'll need i386 for Simulator.
Mit freundlichen Grüßen / Best regards
Alexander Lanin
-Ursprünglich
On Monday March 23 2015 05:46:47 Hausmann Simon wrote:
Hi,
>I think we are talking about the compiler that is used to build qmake here,
>not the tools.
I'm more concerned with the compiler that qmake decides to use after it's been
built!
> (yes, we have some awk hacks in configure to parse th
On Sunday March 22 2015 23:18:17 Thiago Macieira wrote:
>
>The point is that we extract QMAKE_CC and QMAKE_CXX from the mkspec so that we
>can build qmake.
Just to be clear: *my* point is that on OS X those variables are basically
ignored during a Qt build.
>The C compiler is usually called "c
Thiago Macieira wrote:
>
> Anything I missed? Opinions?
As far as I know, qmake `CONFIG += c++11` causes
-std=c++11
or similar to be used on compile and link lines. For the sake of user code,
you might want to use
-std=gnu++11
instead, because
-std=gnu++98
is the default and you turn
On 21/03/15 21:53, "Thiago Macieira" wrote:
>On Saturday 21 March 2015 18:55:52 Edward Sutton wrote:
>> When cross-compiling Qt for embedded use, are C++11 compilers always
>> available?
>
>Yes, of course. Embedded targets use GCC too.
>
>But that's not relevant to this discussion.
>
>> Personall
> On Mar 21, 2015, at 7:40 PM, Thiago Macieira
> wrote:
>
> We'd like to make Qt build unconditionally with the latest version of the C++
> standard that is supported by the compiler. That implies removing the -c++11
> option so that the -no-c++11 option goes away too.
>
> Possible drawbacks
22 matches
Mail list logo
