I was trying to investigate #679874 (as I suspect I've seen similar
problems with the FTBFS bug against qmf) but I am also developing
Qt applications for armel on the same machine, so I have
the following multiarch variants installed:

ii  libqt4-dbus:armel
ii  libqt4-sql:armel
ii  libqt4-sql-sqlite:armel
ii  libqt4-xml:armel
ii  libqtcore4:armel
ii  libqtgui4:armel

The architecture detection code in qt4-x11 has a problem:

                    -system-libtiff \
                    -system-libpng \
                    -system-libjpeg \
                    -no-rpath \
                    -optimized-qmake \
                    -dbus-linked \
                    -reduce-relocations \
                    -no-separate-debug-info \
                    -verbose \
                    -gtkstyle \
                    -system-nas-sound \
                    -no-openvg \
                    -lfontconfig \
                    -I/usr/include/freetype2 \
                    -qvfb \
                    -icu \
                    -plugin-sql-ibase -plugin-sql-sqlite2 -arch armv6 -opengl es2
Determining system architecture... (Linux:3.2.0-3-amd64:x86_64)
    64-bit AMD 80x86 (x86_64)
    'arm' is supported
    'x86_64' is supported
System architecture: 'arm'
Precompiled-headers support enabled.

Yes, maybe arm should be supported because I'm also developing for armel but qt4-x11 should
not be able to pick that up as an indication to try and build with the system architecture
set to arm! This isn't a cross-build.

It looks like it's doing a simple alphabetical sort and picking the first arch it
finds if there is more than one ... that is going to cause unexpected failures, like
this one.

The build continues and fails, first at opengl:

OpenGL ES 2.x auto-detection... ()
make[2]: Entering directory `/home/neil/code/debian/src/qt/qt4-x11-4.8.2/config.tests/unix/opengles2'
g++ -c -pipe -O2 -Wall -W -DQT_WEBKIT -I../../../mkspecs/glibc-g++ -I. -I/usr/include/freetype2 -I/usr/X11R6/include -o opengles2.o opengles2.cpp
opengles2.cpp:45:25: fatal error: GLES2/gl2.h: No such file or directory
compilation terminated.
make[2]: *** [opengles2.o] Error 1
make[2]: Leaving directory `/home/neil/code/debian/src/qt/qt4-x11-4.8.2/config.tests/unix/opengles2'
OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and QMAKE_LIBS_OPENGL_ES2 in
 /home/neil/code/debian/src/qt/qt4-x11-4.8.2/mkspecs/glibc-g++.
make[1]: *** [override_dh_auto_configure] Error 1

(This will be because I don't have libqt4-opengl:armel installed, but that's not
the point.)

The build then fails later (if I mangle the package to avoid opengl) at an attempt to try
and compile the arm assembly code.... Oops.

Note how, despite selecting a system architecture of arm, it is using g++ not
arm-linux-gnueabi-g++ or x86_64-linux-gnu-g++.

Unfortunately, this makes things very difficult for me to test bugs in qt4-x11
and it will also make it hard to debug multiarch builds once the GSoC project for
Emdebian provides MultiArch cross-compiler toolchains.

On Vie 27 Jul 2012 20:11:13 Neil Williams escribió:
[snip]

Hi Neil! First of all, it's late in the night here so I probably shouldn't be
answering bugs, but when I read your report I saw that you didn't mention
which version of libqt4-dev you have installed. Please note that the headers
are not arch-independent.

I may be missing some point here, if so, please feel free to point me out.

Kinds regards, Lisandro.

On Vie 27 Jul 2012 20:11:13 Neil Williams escribió:
[snip]

Hi Neil! First of all, it's late in the night here so I probably shouldn't be
answering bugs, but when I read your report I saw that you didn't mention
which version of libqt4-dev you have installed. Please note that the headers
are not arch-independent.

I may be missing some point here, if so, please feel free to point me out.

Kinds regards, Lisandro.

libqt4-dev is at the same version as all the other qt4-x11 packages
installed.

$ dpkg-query -W libqt4-dev:amd64
libqt4-dev	4:4.8.2-1

I think I am expecting more than MultiArch can deliver right now.
I was hoping, later, to test some MultiArch cross-compilers with Qt but
it looks like the incomplete spec for -dev packages is going to prevent
that. That's why the armel *libs* are installed, not an armel
libqt4-dev.

Not necessarily. However, the mere presence of the armel MultiArch
libraries shouldn't break libqt4-dev:amd64 for amd64 builds on an amd64
machine. The amd64 build shouldn't be looking in the armel MultiArch
paths. Currently, it looks like it is looking in all paths and then
mishandling the situation where it finds more than one. It shouldn't be
looking for more than one but if it does and finds more, it should bail
early and not "just pick one".

So far, I've not had problems building amd64 versions of my Qt packages
on amd64 but when I come to build qt4-x11 itself (not as Qtembedded but
just as Qt) for amd64 on amd64, it fails because of the MultiArch
*libraries* installed. That's unexpected and nothing to do with the
headers themselves not being arch-independent. *Something* in the
qt4-x11 configuration step is locating libqtcore4:armel as well as
libqtcore4:amd64 and deciding - on that basis alone - that the qt4-x11
build itself needs to build for amd64 & armel but because it's not
expecting a list, it takes the first arch in the list, sorted
alphabetically, and assumes that!

That's a bug - Qt should expect to be told the build and host
architectures, not magically assume based on the *libraries* (not -dev
packages) currently installed.

Qt is a complex build, it doesn't help if it adds to that complexity by
using hidden assumptions.

For now, I'll uninstall the :armel libraries for Qt and try again later
but maybe this should be forwarded upstream as a Qt build system issue.

On Dom 29 Jul 2012 05:07:01 Neil Williams escribió:
[snip]

Indeed.

[snip]

Forwarded upstream. I have checked ./configure --help options and couldn't
find any reference to this kind of options.

Kinds regards, Lisandro.

Upstream just said it will investigate the issue if it also happens in
Qt 5 (not yet available in Debian).

Source:
<https://bugreports.qt-project.org/browse/QTBUG-26854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185824#comment-185824>

tag 683036 moreinfo
thanks

Hi Neil! Would you mind trying the same with Qt5 in experimental? Upstream
will not take a look at this in Qt4, but if it happens in Qt5 the fix may be
backported.

You want to get qtbase-opensource-src.

Thanks!

tag 683036 moreinfo
thanks

Hi Neil! Would you mind trying the same with Qt5 in experimental? Upstream
will not take a look at this in Qt4, but if it happens in Qt5 the fix may be
backported.

You want to get qtbase-opensource-src.

Thanks!

-- 
Greeting,

I have access to very vital information that can be used to
move huge amounts of money.

If it was possible for me to do it alone I would not
have bothered contacting you. Ultimately I need you to play an
important role in the completion of this business transaction.

Regards,
Mr Alexander Bulyanda