Ah thanks, that works, i had gcc installed but not g++ it seems.

Strangely, i cannot run demos as even if i make the executables runnable, then i get something like this:

after making the qt teaservice.desktop demo executable as a program in its right click properties and trying to run.
Somehow i get the impression that this is not what i am meant to be doimng anyway, as the idea that i would have to right click and change the permissions of all the demo files that i wanted to run doesn’t seem the most fun so i guess i am trying to do it the wrong way :$

Also, i tried to compile qt creator and the qtquick3d demos myself and got errors.
(For example, for the qtquick3d):

Sorry to be a pain.

Greetings guys,

On Windows 7 ×64 I get the following:

It seems that the SPI_GETDROPSHADOW is under a WIN_NT_32 define.

I just restarted my attempt at building Qt5 after spending a day finding out that wayland isn’t ready for Debian Wheezy amd64 yet.

By running configure with the “-v” switch I could see the auto-detection tests and their results – I needed to install libasound2-dev for Alsa.

Note:

does nothing – “confclean” isn’t a valid makefile target, although configure tells you to use this to clean up before another configure run.

Maybe someone could add

to the right makefile to tie things up.

Also, see the

error after the “rm -f …” entries below.

The error is

This is a “bashism” – something only bash understands.
Although /bin/sh was usually symlinked to /bin/bash, on Debian Wheezy /bin/sh -> dash.

“dash” and therefore “sh” doesn’t recognise “[” and doesn’t like “==”.

It occurs lots of times in this configure script – maybe in others too.

Somehow it muddles through. I’d recommend using “set -e” to catch these.

Anyway here’s my configure output, after doing the recursive clean command above.

Here’s a list of files I had to modify on my way to discovering that libQtdesigner is needed for qtbase/plugins/designer/libqwebview.so but wasn’t built yet.

This needs “Qt += quick”

This needs to “#include <QNetworkCookie>”

This uses “ QTouchEvent::TouchPoint::Primary” – I commented it (and the “if” statement) out to get further.

This needs “Qt += quick”

This needs to “#include <QNetworkCookie>”

These need “Qt += quick”

This wasn’t tested with “regular” OpenGL

Here’s the change I made to it.

These assume they’re only included from within WebKit – untrue.
Yes, I later realized that this isn’t the right place to change them.

Hope this helps.

I had to choose between OpenGL and GL ES2 but I could also select xcb.

Isn’t qpa building about being able to select between all of these at run-time?

On Debian Wheezy I’ve got the libraries and development packages installed to support OpenGL and GL ES2.

Also, maybe “build.stamp” and “install.stamp” files marking modules as built/installed could help “make” or “make install” skip modules entirely and speed things up.

If specifying “-prefix $PWD/qtbase” is your way of saying Qt5 isn’t ready for “-prefix /usr” then you could have made that point a little more prominently.

Philius, I think it would be nice if you posted your findings to Qt development mailing list, where devs are likely to pick it up. And/ or modifying the Building Qt5 from Git [developer.qt.nokia.com] wiki page might be a good idea.

I re-subscribed and posted an email with a QtWebkit patch although my build still (eventually) fails.

I think that as long as the install prefix is inside the source tree (not to mention the build path!) you’re going to have problems, so I won’t try it again at least until these things change.

From trying to fix problems I noticed that there are several “Release” directories created in the source tree – it looks like someone was at least trying to do some whacky kind of out-of-source-while-still-in-source deal.

Do a “find . -type d -name Release” once you’ve tried to build it at least once to see the strangeness.

I also noticed that the build process was picking header files from the install path in preference to the source directory – I’ve got projects that use automake that don’t do that (it’s a shame automake can’t do the same for libraries).

Then there’s “make install” trying to copy files over themselves.

I’ll stop here.

On OSX I got stuck with a conflict of MacTypes.h

http://code.google.com/p/webkit-mirror/source/detail?r=a84882c321ecf749f61a855f1538aeaf938b2340 [code.google.com]

Here are some links to patches that address some of the problems mentioned by Philius:

https://gist.github.com/1647614 [gist.github.com]
https://bug-76463-attachments.webkit.org/attachment.cgi?id=122778 [bug-76463-attachments.webkit.org]

Those “QT += quick” are needed on Debian Wheezy because of

I can confirm that all of changes mentioned by Philius are required to build on OSX.

I also needed to add – “QT += quick” to the following files:

./qtwebkit/Source/WebKit/qt/declarative/public.pri
./qtwebkit/Source/WebKit/qt/declarative/experimental/experimental.pri
./qtwebkit/Source/WebKit2/UIProcess/API/qt/tests/tests.pri

Philius – I think there are a few small mistakes in your earlier post which may be misleading to some – you say add “Qt += quick” which I believe should be “QT += quick” with upper case T

Yep.
While packaging my projects to get them into Debian I had my wrist slapped for referring to Qt as QT, which is QuickTime.
It must have stuck in my head.
They’re spelled correctly in the patch, and anyway sometimes you have to append “quick” to the existing “QT =” or “QT +=” line.

Very true about appending it in some cases.

I was wondering have you been testing qtwebkit at all? On OSX the build seems to be adding incorrect paths from the binaries to the dynamic libraries. I’ve fixed them up but MiniBrowser and QtTestBrowser are still not quite working properly yet. I’m going to look into it more later. I just wondered if the situation was looking any better on Linux? I’m going to try building on Ubuntu next.

I just started a shadow build.
Here’s the makefile (same dir as qt5).

The includes are for gstreamer support.

It looks like OpenVG and Phonon aren’t ready yet.
The error for them is “QMAKESPEC has not been set, so configuration cannot be deduced”.

I’ll report back when it’s done.

It looks like the build system doesn’t track configure changes – gstreamer seems to require phonon.

I’ll “make clean” and “try” yet again.

Out of source builds definitely don’t work, although this could change with new updates.

I’m not sure why the separate packages aren’t “configure && make && make install” -able individually.
Maybe this is just to get them built quicker, but then they aren’t really separate packages.

Also, providing text instructions that (currently) conflict with the README in git isn’t helpful.
One of them should change.

Next, there should be a top-level “make” script which builds the tested configuration.
export “$ROOT” to the absolute path to the qt5 directory for the comments below.
I added

otherwise svg and phonon modules fail.

I added

otherwise qmake won’t find qmodule.pri.

I added

To use the binaries built in the build tree and not those installed on my system.

It still fails with the following error:

GL_READ_FRAMEBUFFER_EXT is defined in GL/glext.h but not in OpenGL ES2, at least not in Wheezy amd64.