Re: [Interest] Qt 5.5 and Red Hat 5
On 21/03/15 20:19, Thiago Macieira wrote: On Thursday 19 March 2015 14:41:24 Nikos Chantziaras wrote: Qt 5.5 will provide support for Windows 10 (when available) and RedHat Enterprise Linux 6.6. From http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/ RHEL 6.6 comes with glibc 2.12, which isn't affected by these issues. See http://distrowatch.com/table.php?distribution=redhat Again, the problem is RHEL 5, which has glibc 2.5. How is the C++11 situation here though? I assume RHEL 6 support in Qt comes without C++11 due to the ABI incompatibilities between the toolset and vanilla RHEL? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Is the OpenGL vs Angle distinction important for widget apps?
For applications that don't use Qml and only use QWidget, does it matter whether Qt was built with OpenGL or Angle on Windows? As far as I can tell, GL/Angle is only used by Qml. Is that true? Can there be any circumstances where a non-Qml application might error out if running with an OpenGL-based Qt on a system with an old OpenGL version? (Meaning the default one from Microsoft which only supports software OpenGL 1.1.) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On 21/03/15 20:19, Thiago Macieira wrote: On Thursday 19 March 2015 14:41:24 Nikos Chantziaras wrote: Qt 5.5 will provide support for Windows 10 (when available) and RedHat Enterprise Linux 6.6. From http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/ RHEL 6.6 comes with glibc 2.12, which isn't affected by these issues. See http://distrowatch.com/table.php?distribution=redhat Again, the problem is RHEL 5, which has glibc 2.5. How is the C++11 situation here though? I assume RHEL 6 support in Qt comes without C++11 due to the ABI incompatibilities between the toolset and vanilla RHEL? If you use a modern devtoolset, like 1.x/2.x, you can have C++11 on both RHEL 5 6 without any problems. The CI wiki states they use gcc 4.9.1 on RHEL 6 (at least from qt 5.5.0 on), guess that means devtoolset = 2.x See https://wiki.qt.io/Qt-5.5.0-tools-and-versions Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Is the OpenGL vs Angle distinction important for widget apps?
As long as the application is pure widgets, without ever using QOpenGL/QGL classes or QQuickWidget, it will not attempt to initialize any OpenGL stuff. (if that's not the case, it's a bug, we had some of these recently, like QTBUG-43832) This means that not having OpenGL or ANGLE working (or available) is not a problem for such apps. Starting with 5.5 the only type of pre-built packages for Windows are the dynamic GL ones, so the confusion of needing to ship ANGLE libs even for widget-only apps will go away. Cheers, Laszlo From: interest-bounces+laszlo.agocs=theqtcompany@qt-project.org interest-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Giuseppe D'Angelo dange...@gmail.com Sent: Sunday, March 22, 2015 4:48 PM To: Nikos Chantziaras Cc: interest@qt-project.org Subject: Re: [Interest] Is the OpenGL vs Angle distinction important for widget apps? On 22 March 2015 at 10:28, Nikos Chantziaras rea...@gmail.com wrote: For applications that don't use Qml and only use QWidget, does it matter whether Qt was built with OpenGL or Angle on Windows? It still matters because 1) ANGLE means extra dependencies to be shipped along your app 2) ANGLE does not work on Windows XP So for pure-widgets applications it might make more sense to use the Desktop OpenGL build of Qt. YMMV :) -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Is the OpenGL vs Angle distinction important for widget apps?
You are forgetting about QtWebEngine. It needs opengl of some sort regardless of whether you use Qml or QWidgets. On Sun, Mar 22, 2015, 09:30 Agocs Laszlo laszlo.ag...@theqtcompany.com wrote: As long as the application is pure widgets, without ever using QOpenGL/QGL classes or QQuickWidget, it will not attempt to initialize any OpenGL stuff. (if that's not the case, it's a bug, we had some of these recently, like QTBUG-43832) This means that not having OpenGL or ANGLE working (or available) is not a problem for such apps. Starting with 5.5 the only type of pre-built packages for Windows are the dynamic GL ones, so the confusion of needing to ship ANGLE libs even for widget-only apps will go away. Cheers, Laszlo From: interest-bounces+laszlo.agocs=theqtcompany@qt-project.org interest-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Giuseppe D'Angelo dange...@gmail.com Sent: Sunday, March 22, 2015 4:48 PM To: Nikos Chantziaras Cc: interest@qt-project.org Subject: Re: [Interest] Is the OpenGL vs Angle distinction important for widget apps? On 22 March 2015 at 10:28, Nikos Chantziaras rea...@gmail.com wrote: For applications that don't use Qml and only use QWidget, does it matter whether Qt was built with OpenGL or Angle on Windows? It still matters because 1) ANGLE means extra dependencies to be shipped along your app 2) ANGLE does not work on Windows XP So for pure-widgets applications it might make more sense to use the Desktop OpenGL build of Qt. YMMV :) -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???
Hi, How come that the bootstrap qmake ignores the mkspec's CMAKE_CC and CMAKE_CXX? I see `/usr/bin/clang++` and `/Developer/usr/bin/clang` (for C and ObjC++) when configure runs the config.test tests, and this causes problems because I need to use the clang compiler specified in my mkspec. NB: build/qtbase/mkspecs/qmodule.pri does contain the correct compiler paths! NB2: the bootstrap qmake in fact ignore the mkspec completely: introducing a syntax error in it doesn't raise an error. I'm OK with patching the qmake code, but will need to know where ... Thanks, R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Is the OpenGL vs Angle distinction important for widget apps?
On 22 March 2015 at 10:28, Nikos Chantziaras rea...@gmail.com wrote: For applications that don't use Qml and only use QWidget, does it matter whether Qt was built with OpenGL or Angle on Windows? It still matters because 1) ANGLE means extra dependencies to be shipped along your app 2) ANGLE does not work on Windows XP So for pure-widgets applications it might make more sense to use the Desktop OpenGL build of Qt. YMMV :) -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] bug: qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???
On Sunday March 22 2015 19:01:55 René J.V. Bertin wrote: I found the immediate culprit: build/qtbase/qmake/.qmake.stash This file sets QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC etc. to values that are completely unrelated to what's specified in the mkspec file. I think that also explains another issue I've had that is also due to the bootstrap qmake ignoring the information from the specified mkspec file. I have not yet figured out where the .qmake.stash file is generated though (pbuilder_pbx.cpp?) but fortunately it appears to be possible to pre-generate a version with the appropriate values before calling configure. R. I had this problem recently, when some files were not being found because qmake was generating targets with the wrong path to clang. I remember that somewhere during the makefile generation qmake runs xcrun --find clang and uses the output as the compiler path, ignoring what you set in QMAKE_CXX. Can’t remember where it does that now, but the fix for me was to hardcode the the paths in the mkspecs/common/clang.conf file (QMAKE_CXX and QMAKE_CC variables). Hope that helps. Samir ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] bug: qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???
On Sunday March 22 2015 19:01:55 René J.V. Bertin wrote: I found the immediate culprit: build/qtbase/qmake/.qmake.stash This file sets QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC etc. to values that are completely unrelated to what's specified in the mkspec file. I think that also explains another issue I've had that is also due to the bootstrap qmake ignoring the information from the specified mkspec file. I have not yet figured out where the .qmake.stash file is generated though (pbuilder_pbx.cpp?) but fortunately it appears to be possible to pre-generate a version with the appropriate values before calling configure. R. Hi, How come that the bootstrap qmake ignores the mkspec's CMAKE_CC and CMAKE_CXX? I see `/usr/bin/clang++` and `/Developer/usr/bin/clang` (for C and ObjC++) when configure runs the config.test tests, and this causes problems because I need to use the clang compiler specified in my mkspec. NB: build/qtbase/mkspecs/qmodule.pri does contain the correct compiler paths! NB2: the bootstrap qmake in fact ignore the mkspec completely: introducing a syntax error in it doesn't raise an error. I'm OK with patching the qmake code, but will need to know where ... Thanks, R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] bug: qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???
On Sunday March 22 2015 21:35:47 Samir Aguiar wrote: I remember that somewhere during the makefile generation qmake runs xcrun --find clang and uses the output as the compiler path, ignoring what you set in QMAKE_CXX. Yes, that's in qtbase/configure, and it basically determines the compiler used to build qmake. It's the first thing I fixed, remove QMAKE_CC and QMAKE_CXX from the switch that queries xcrun. Without that you cannot even hardcode compiler paths in mkspecs/common/clang.conf ... Turns out that was not enough. On Sunday March 22 2015 20:33:53 Hausmann Simon wrote: Should bootstrap really use the mkspec compiler? I'm not sure that's always the right thing. Bootstrap should just use _any_ compiler. Heh, I think I agree to some extent, because a priori any compiler means that you (I :)) have some control over it. As things stand, a very specific compiler is chosen, i.e. the one provided by Xcode. That's fine on recent OS X versions where that means a recent clang version, but not on OS X 10.6 (and maybe even 10.7). The compiler used to build qmake shouldn't matter, as long as it's recent enough, and it'd be useful if one could specify it through $CXX for instance. But I do think that the bootstrap qmake should respect the mkspec. Suppose you want to build with clang on Linux where you also have perfectly a valid gcc which is probably the system default compiler (/bin/cc or something like that). It'd a bit surprising if qmake just used whatever it finds first in that case. One could of course think of a mkspec that has something like QMAKE_CXX=$CXX to tell qmake to use the CXX env. variable (or the system default otherwise). But that's a different topic (though still subject to qmake NOT replacing this setting through .qmake.stash ;)). What is the underlying problem that you are trying to solve? Sorry, this is going to be long! I'm trying to come up with a reproducible build script for MacPorts, on OS X 10.6.8 . On that OS version we have to take 2 Xcode versions in consideration (3.2.6 and a very early 4 series). The former has gcc-4.2 as the default compiler (and an optional very early clang version, 1.7 or so), the latter Apple clang 3.0 . Gcc-4.2 runs the config tests just fine, but chokes on something too modern in QtCore. Apple clang 3.0 doesn't compile all tests: the nis, icu and corewlan ones fail. The former 2 can be patched (and need to for later clang versions too, with the 10.6 SDK). The corewlan test cannot be patched, though. The additional issue is that the MacPorts script (Portfile) cannot easily control what Xcode version is installed or selected, and shouldn't have to force the user to make a choice. So the best way out is to install one of the recent clang versions that are in MacPorts (and *that* is something we can control in Portfiles). That provides clang and clang++ in MacPorts' bin, which is frontmost in the path during builds. So in practice I'm not actually hardcoding a compiler path in the mkspec, but that is only because I figured out how to avoid the hardcoded references to Xcode compilers. There's a related problem that may carry more weight because if affects current OS X and Qt versions. The MacPorts Portfile installs Qt 5.4.1 on OS X 10.7 and later. It can also generate a universal build, using 2 separate builds which are lipoed together at the end. That requires cross-bitwidth compilation, e.g. 23bit on a 64bit system. That's easy enough on paper; just use the macx-clang-32 mkspec, and that works for everything but QtWebEngine. That is in fact what the Portfile installs in a single go, giving me a universal Qt 5.4.1 installation missing just that 1 component. The QtWebEngine component is a separate port. To build it, we extract just the qtwebengine directory from the qt-everywhere tarball, and then invoke the installed qmake (/opt/local/libexec/qt5/bin/qmake -r ../qt-everywhere*/qtwebengine/qtwebengine.pro) with either macx-clang or macx-clang-32 . And that's where things go wrong: when called inside the Qt source tree, the *installed* qmake ignores the m kspec file. Outside that source tree it works exactly as expected, but not inside the tree. Note that we're talking about a fresh checkout here, so there is no .qmake.stash before I call qmake. I'll be having another look at this issue when I'm done working on the 10.6.8/Qt5.3.2 build. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [qt-android] How to build qt for android with neon support?
On Sunday 22 March 2015 10:16:09 Liang Jian wrote: As you can see, neno is not enabled, what is wrong with my configuration? Nothing. Neon is never enabled by default. To enable it, edit the mkspec and add the flags: -mfpu=neon You may need to adjust the -march option too. Your binaries will not run on CPUs without Neon. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5 and Red Hat 5
On Sunday 22 March 2015 11:36:37 Nikos Chantziaras wrote: On 21/03/15 20:19, Thiago Macieira wrote: RHEL 6.6 comes with glibc 2.12, which isn't affected by these issues. See http://distrowatch.com/table.php?distribution=redhat Again, the problem is RHEL 5, which has glibc 2.5. How is the C++11 situation here though? I assume RHEL 6 support in Qt comes without C++11 due to the ABI incompatibilities between the toolset and vanilla RHEL? The C++11 situation is dictated by the compiler you choose to use for your application. If you're targetting RHEL 5 or 6, I assume you don't want new features. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
