[kde-freebsd] Fixing devel/qt4-corelib to build with clang

Dimitry Andric dimitry at andric.com
Wed May 8 11:48:47 UTC 2013


On 2013-05-08 13:18, Raphael Kubo da Costa wrote:
> Dimitry Andric <dimitry at andric.com> writes:
>> However, for 3DNow intrinsics, the header has something different:
>>
>>    #if defined(QT_HAVE_3DNOW)
>>    #include <mm3dnow.h>
>>    #endif
>>
>> As you can see, there is no test whether the compiler defines __3dNOW__,
>> so if the configuration stage enables QT_HAVE_3DNOW (as it does for
>> clang, but not for gcc), it always includes <mm3dnow.h>, even if the
>> compiler's current mode does not support it.  This is a bug in Qt.
>>
>> So I changed this part to the following (similar to the other intrinsics
>> includes):
>>
>>    #if defined(QT_HAVE_3DNOW) && (defined(__3dNOW__) || defined(Q_CC_MSVC))
>>    #include <mm3dnow.h>
>>    #endif
>
> This still looks weird to me: QT_HAVE_3DNOW should only be defined if
> the test in config.tests/unix/3dnow/3dnow.cpp passes. It's supposed to
> fail to build with clang-i486 just like qsimd.cpp.

Those tests do not fail, because during the tests, the appropriate
parameters are passed, e.g. -m3dnow, -msse and so on.  For example, if
you look at the Makefile for the 3dnow test in
${WORKDIR}/qt-everywhere-opensource-src-4.8.4/config.tests/unix/3dnow,
it has:

   CXXFLAGS      = -pipe -m3dnow -O2 -pthread -D_THREAD_SAFE -Wall -W $(DEFINES)

This originates in the top-level configure script, which has:

   # detect 3dnow support
   if [ "${CFG_3DNOW}" = "auto" ]; then
       if "$unixtests/compile.test" "$XQMAKESPEC" "$QMAKE_CONFIG" $OPT_VERBOSE "$relpath" "$outpath" config.tests/unix/3dnow "3dnow" $L_FLAGS $I_FLAGS $l_FLAGS "-m3dnow"; then
	  CFG_3DNOW=yes
       else
	  CFG_3DNOW=no
       fi
   fi

and similar for all the other SIMD instructions.  So this stage detects
if the compiler *can* support a particular set of SIMD instructions, not
whether such a set is enabled by default.

In any case, there is a difference between what is detected for (base)
gcc and clang.  For gcc, the configure stage displays:

   Build type:    /usr/local/share/qt4/mkspecs/freebsd-g++
   Architecture:  i386

   Build .................. libs tools examples demos docs translations
   Configuration ..........  release shared dll largefile stl mmx sse sse2 sse3 ssse3  minimal-config small-config medium-config large-config full-config qt3support phonon accessibility opengl reduce_exports ipv6 clock-gettime clock-monotonic getaddrinfo ipv6ifname getifaddrs system-jpeg system-mng system-png png system-tiff system-freetype system-zlib nis gnu-libiconv glib openssl x11sm xshape xvideo xsync xrender mitshm fontconfig xkb icu concurrent xmlpatterns multimedia audio-backend svg script scripttools declarative release
[...]
   MMX/3DNOW/SSE/SSE2/SSE3. yes/no/yes/yes/yes
   SSSE3/SSE4.1/SSE4.2..... yes/no/no

That gcc in base does not support sse4.x is expected.  However, the
3dnow support test fails, because for some reason, the FreeBSD Makefile
for base gcc does not install mm3dnow.h.  (I will fix this in FreeBSD,
but I think that after installing the header, qt4-corelib would fail in
the same way it failed for clang. :-)

For clang, it displays instead:

   Build type:    /usr/local/share/qt4/mkspecs/freebsd-clang
   Architecture:  i386

   Build .................. libs tools examples demos docs translations
   Configuration ..........  release shared dll largefile stl mmx 3dnow sse sse2 sse3 ssse3 sse4_1 sse4_2 avx  minimal-config small-config medium-config large-config full-config qt3support phonon accessibility opengl reduce_exports ipv6 clock-gettime clock-monotonic getaddrinfo ipv6ifname getifaddrs system-jpeg system-mng system-png png system-tiff system-freetype system-zlib gnu-libiconv glib openssl x11sm xshape xvideo xsync xrender mitshm fontconfig xkb icu concurrent xmlpatterns multimedia audio-backend svg script scripttools declarative release
   [...]
   MMX/3DNOW/SSE/SSE2/SSE3. yes/yes/yes/yes/yes
   SSSE3/SSE4.1/SSE4.2..... yes/yes/yes

So for clang, all SIMD support is properly detected, and enabled.

(Note there is also another, unrelated difference: for gcc it detects
'nis' support, but not for clang...  No idea why yet.)


> The way we build each Qt component separately may make the build system
> confused.
>
> I'm at $WORK right now, and ref10-i386 lacks some of the Qt dependencies
> for me to perform some tests, so can you check if devel/qmake4 and
> devel/qt4-corelib have a .qmake.cache file in their work dir that end up
> with "3dnow" somewhere in their "CONFIG +=" line?

The qmake4 work dir does not have any .qmake.cache file.  For
qt4-corelib, there is one, and it has this line:

   CONFIG +=  release shared dll largefile stl mmx 3dnow sse sse2 sse3 ssse3 sse4_1 sse4_2 avx dylib create_prl link_prl depend_includepath fix_output_dirs QTDIR_build

but as shown above, this is completely as expected.

-Dimitry


More information about the kde-freebsd mailing list