We have a desktop application built with Qt 4.8.4 which makes use of ICU. I am now porting that application to Qt 5.2.1. I notice a new configure option: -icu. What does this do? I'm trying to determine if I should use it or not.
I've read that it "enables ICU support." What does that mean? And does that matter for porting an application that is already using ICU under 4.8.4?
In case it matters: we plan to build on Windows, Mac OSX, and several Linux distros.
Note: our application does not use webkit.
Related
I am setting up a Qt project which will be cross-copiled for a given display (running on ARM/Linux). The display will come with a self-contained cross-build toolchain which comprises Qt libraries with a specific Qt version (probably 5.15).
Now I would like to use a specific "static" toolchain incl. Qt libraries to also generate x86-builds of this Qt project (for testing, simulation; building/running on Linux and maybe also on Windows).
I'd avoid using the GCC and Qt development files introduced by the Linux package manager (e.g. apt), because the are not tied to a specific Qt version, i.e. upgrading the OS would always come with the risk to introduce build problems or break compatibility completely.
Are there good-practice approaches to achieve this?
So far I see three options:
Use a docker image
Possible problems:
Finding a image with the correct Qt version
building the Qt application would then work, but to execute it, the compatible Qt LGPL shared libs need to be available to the Qt application binary
Use a x86 -> x86 "standalone" toolchain
Find some standalone x86-toolchain analog to those (x86 -> x86), but additionaly...
it would either have to come with the Qt development files in the correct version
or we would have to build the Qt sources with this toolchain, and then extend the toolchain with the Qt built artifacts
Would be the preferred solution (and currently seems to be the most feasible of the approaches I can think of).
Virtual machine
Possible problems:
Finding a OS version with the correct Qt version
Select a OS version that contains the correct Qt version via package manager.
Not very elegant.
Qt online installer
only provides a limited choice of Qt versions (as of today: 5.15.2, 6.2.4, 6.3.2, 6.4.0) which is probably subject to change in the future
When building former version of qtconnectivity lib, official site said I could use -native-win32-bluetooth to enable native bluetooth API, like qmake -- -native-win32-bluetooth, but how could I use this flag when building the new version lib with cmake?
Since you talk about CMake, I assume you talk about Qt 6. Qt 6 doesn't support the native Win32 Bluetooth API anymore, see also https://doc-snapshots.qt.io/qt6-dev/whatsnew62.html :
Win32 backend was removed. As a consequence, there is no longer support for Qt Bluetooth using MinGW.
I've been evaluating QT Jambi for an application I'm developing, and on the way I've read that QT Jambi faces some troubles at development time on Win64. However, I won't develop on Win64 so it doesn't matter for now, but what I really need to know is whether an application that is built using QT Jambi would run seamlessly on Win64 or not.
Thanks,
There is basic support for win64 already present, there just haven’t been releases for that platform. So I assure you, win64 will work as win32 does, there shouldn’t be any differences.
I need to port one of my old program to Windows. The current version uses Qt 3 on Linux.
I'd like to see it within few days only to do some tests.
Instead of porting my code on Qt 4 (no time now), is it possible to recompile on Windows with Qt 3? Do I also need minGW? Which problems may I have doing this porting?
I can't find Qt 3 for windows, can someone give me a link? or I can use the same qt source I use on Linux?
Yes, you can !
Download the qt-win-3.3.x-8 project on Sourceforge.
QT4 still has back-compatible QT3 classes, prefixed with Q3* (see http://qt-project.org/doc/qt-4.8/qt3support.html)
You should be able to compile & run you QT3 app on QT4 via those classes with minimal adaptations.
Qt-3.2 for Windows was also distributed in a CD bundled with the book "C++ GUI programming with Qt3" at no additional cost with a license for non-commercial use.
ISBN: 978-0131240728
The supported compilers were MSVC and Borland. MingW is not mentioned.
I am developing an application in Qt, but using D language (with QtD binding). I've noticed that my app crashes with Qt 4.7.x, so I need to use Qt 4.6.2 instead. However in my system Qt 4.7.2 is installed. Unfortunately I neither make QtD work with the latest Qt versions nor (I'm afraid) count on QtD developers...
The only thing I need to make my application install in system Qt 4.6.2 libs and use it, but let all the other applications still use Qt 4.7.2. Is it possible? If it is, how to do it then?
The answer to your question is the version of Qt is determined by the qmake you use to generate your Makefile.
/opt/QtSDK/Qt-4.6.2/bin/qmake
/opt/QtSDK/Qt-4.7.3/bin/qmake
Each will use the library in the directory.
It is possible to install several versions of the library into one system, and all package managers (rpm, deb) support this out of the box.
These libraries will be just differently named. For example, if id do
ls /usr/lib/ | grep libcurl
on my system, I'll get:
libcurl-gnutls.so.3
libcurl-gnutls.so.4
libcurl-gnutls.so.4.2.0
libcurl.so.3
libcurl.so.4
libcurl.so.4.2.0
, so, different version of the same library happily live together.
All you need to do is to link against the desired version of QT library. You need to sepcify it in linker options (don't remember the exact option).