I'm trying to get Qt applications running on QNX 4.5. I've compiled Qt 4.6.3 on a linux box with this configuration:
./configure -xplatform unsupported/qws/qnx-i386-g++ -embedded i386 -no-gfx-linuxfb -no-mouse-linuxtp -no-kbd-tty -no-qt3support -qt-gfx-qnx -qt-mouse-qnx -qt-kbd-qnx -no-exceptions -little-endian -nomake demos -nomake examples
"make" required certain tweaking of environment and commenting out one function, but worked in the end. I've copied fonts and compiled Qt libraries onto QNX running in VMware, and created a sample Qt app (it just displays a button) which I compiled on my linux box and copied over to QNX.
I have a little script to launch the app:
io-display -d vid=0x15adh,did=0x405h
/usr/photon/bin/devi-hid -Pr kbd mouse
./app
Which runs the application, enabling experimental input drivers. With this script I was able to get somewhere by running the Qt app in Photon - screen rendering gets all screwed up, but I do see my Qt application.
However, if I exit Photon into a text mode, and try to run the application from there (using a slightly modified script with different vid and did values for launching the graphics server), I just see a blank screen.
I'm completely new to QNX and Qt, so I'm a bit stuck right now. I'm trying to read up on how Photon works and what kind of environment it sets up, to find what I might be missing in the text mode. However, I'm not sure this is even a right direction, so I thought I'd ask good folks on SO, in case somebody went through this before :)
cheers!
Have you tried adding "-qws" after you app? It tells the Qt app to initialize it's windowing system (qws). Only 1 qt app needs (or may have) the option specified.
I would also add a couple of environment variables to help Qt to know where to find your keyboard and mouse. (I also am not sure if you really need the first line.)
io-display -d vid=0x15adh,did=0x405h
/usr/photon/bin/devi-hid -Pr kbd mouse
export QWS_DISPLAY=qnx
export QWS_MOUSE_PROTO=qnx
export QWS_KEYBOARD=qnx
./app -qws
BTW, QNX has just released a port of Qt 4.7.1 for QNX 6.5. It can be found on the Foundry 27 Qt Project site.
Related
I am very frustrated with QT. I cannot get it to debug appropriately. It will skip breakpoints. I am in debug mode, using debug window.I have cleaned the project, and removed all debug and release directories that were created. Using Fedora 21.
I am also very reluctant to leave QT because the built-in Vim-emulator in it is so clean. I have Googled the hell out of this problem but the suggestions give I have either tried without success or they are explained at a level of ability above my own.
In any case, does anyone know of the solution to this that is able to explain it in a manner which is easily followed? Or, if you know of any IDE (C++) out there that has a comparable Vim plug-in that would be awesome as well. Thanks for your time, apologies for my novice-ness.
rhurac ~/build-HashTable-Desktop_Qt_5_5_0_GCC_64bit-Debug $ cat Makefile
Makefile for building: HashTable
Generated by qmake (3.0) (Qt 5.5.0)
Project: ../HashTable/HashTable.pro
Template: app
Command: /opt/Qt/5.5/gcc_64/bin/qmake -spec linux-g++ CONFIG+=debug -o Makefile ../HashTable/HashTable.pro
The problem is not with Qt but with the debugger (gdb?) incorrectly configured in environment you use. My overall experience with debugging Qt executable modules on Linux was productive. Just because you also want to take advantages of IDE: use Qt own Qt Creator and that most likely integrates gdb properly. If you in fact use Qt Creator but experience difficulties, mind gdb settings: Configure Qt Creator to work with GDB.
And skipping breakpoints may also imply that you need to turn compiler optimizations off for your debug mode.
And for VIM mode in Qt Creator: http://doc.qt.io/qtcreator/creator-editor-fakevim.html
I have built a static x86 Qt5.5 library with VS2013 using:
configure -static -prefix D:\Qt\qt-5.5.0-x86-static -opensource -release -static-runtime -nomake examples -no-compile-examples -static-runtime -nomake tools -no-iconv -qt-zlib -skip qtwebkit -confirm-license -qmake -opengl desktop -no-angle -nomake tests -target xp
After that I used this static library build a static-link exe of my Qml App. It can run everywhere in my windows which has been installed Qt5.5.
Then I used VMware Workstation to install a pure Windows XP SP3 only installed VC2008 runtime not VC2013 runtime.
Firstly, I copy the exe into this XP. It can run but had nothing to show. I need kill it in taskmgr.
Second, I copy all folders in D:\Qt\qt-5.5.0-x86-static\qml to the root dir of my exe, it can run. But it shows me only a blank window with correct window title.
I think I have listen all the advise in Deploying Qt 5 App on Windows. But why the qml parts cannot be compiled into static library? How can I let my app not show blank?
P.S. Even if I use windeployqt to deploy share-link library version of app. It also shows me blank window. But it can run on Windows 7.
The output of qtdiag on my virtual XP:
Qt 5.5.0 (i386-little_endian-ilp32 static release build; by MSVC 2013)
on "windo ws" OS: Windows XP [winnt version 5.1.2600]
Architecture: i386; features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
Library info: PrefixPath: D:\Qt\qt-5.5.0-x86-static
DocumentationPath: D:\Qt\qt-5.5.0-x86-static\doc HeadersPath:
D:\Qt\qt-5.5.0-x86-static\include LibrariesPath:
D:\Qt\qt-5.5.0-x86-static\lib LibraryExecutablesPath:
D:\Qt\qt-5.5.0-x86-static\bin BinariesPath:
D:\Qt\qt-5.5.0-x86-static\bin PluginsPath:
D:\Qt\qt-5.5.0-x86-static\plugins ImportsPath:
D:\Qt\qt-5.5.0-x86-static\imports Qml2ImportsPath:
D:\Qt\qt-5.5.0-x86-static\qml ArchDataPath:
D:\Qt\qt-5.5.0-x86-static DataPath: D:\Qt\qt-5.5.0-x86-static
TranslationsPath: D:\Qt\qt-5.5.0-x86-static\translations
ExamplesPath: D:\Qt\qt-5.5.0-x86-static\examples TestsPath:
D:\Qt\qt-5.5.0-x86-static\tests SettingsPath:
Standard paths [... denote writable entry]: DesktopLocation:
"Desktop" *C:\Documents and Settings\Administrator\
The final conclusion:
The problem is the graphic driver in my virtual Windows XP. It can run on other real PCs.
But there is a sad problem to static build of QML.
I have found this:
https://forum.qt.io/topic/22035/qml-apps-not-runnable-using-static-build-up-to-qt-5-0-1-release/24
The reason why I need copy such folders Qt QtQuick.2 QtQuick is that those lib cannot be compile-loaded. Even if I add them into .pro file. From Qt 5.0 to Qt 5.5. The official side seems do not like people use QML by static-link. So, it is waste of time to do static build of QML app.
Qt Quick applications need 3d acceleration in order to work. This is based on either OpenGL, DirectX via Angle or some kind of software renderer that comes with the commercial version of Qt. Since you specifically exclude Angle in your config, you need a proper OpenGL driver. Make sure that OpenGL works on your machine. You'll find tools for that.
I don't think that is has something to do with missing C++ standard libraries (VC2013 runtime), because in this case your application would crash during start and not run. Qt Quick graphic issues however often lead to a running black app that is writing warnings to the console.
Further debugging can be done using the qtdiag.exe command line tool that comes with Qt (It comes with the online installer. I don't know where it is when you build from source). It checks for you which graphic driver is used and often can show error messages.
I am not able to run programs from Qt Creator, I am always getting error:
Starting C:\path\to\executable\program.exe...
Failed to start program. Path or permissions wrong?
C:\path\to\executable\program.exe exited with code -1
It happened after I built Qt statically. What I did:
Installed Qt 5.2.0 with MinGW from official site (including source component), then installed Python 2.7.6 and Perl. Then built Qt statically from path\to\qt\5.2.0\Src and it showed no errors. After this everything was fine. But when I added new path to qmake.exe (in Qt Versions tab, Build & Run Options section) and added new Kit (Kits tab) with this version I started getting this error. Moreover, now all .exe files have yellow shield near the icon in the Explorer (no matter they were built statically or not). It means that they use administrative privileges, but before I added new Kit executables had no yellow shield! For statically built programs it is fine that Creator can't run them because of administrative privileges that the use, but what happened to dynamically linked programs? I didn't touch any other settings except for adding new Kit.
Edit:
I am using MinGW on Windows 8.1,
qt was configured with this line:
configure.exe -release -opensource -c++11 -static -no-opengl -no-angle -no-vcproj -platform win32-g++ -nomake examples -nomake tests
I seem to have exactly the same problem as iamnp.
In my case, this is an application that compiles and runs smoothly on Windows 7 with Qt 4.8. Adding to the issue is that I'm switching both operating system (Windows 8.1) and Qt version (Qt 5.2) at the same time. But, I wouldn't be surprised that I and iamnp are actually not the only people having this issue.
I have tried the solution of Guilherme (i.e. run QT Creator as administrator), but this didn't resolve the problem.
If somebody has some other idea on what I should try, let me know. In the meantime, I'll try to test this in a minimal application to see what happens.
I've got this qt app1 that I've cross-compiled using cmake and openembedded. It's cross-compiled from i686 to geode, so I figure I should be able to run it on the i686 host I compiled it on, if I link against the geode libraries. As you can see from the image, it doesn't run quite right. Using strace seems to indicate that qt is using some funny encoding for everything, e.g.:
stat64("\342\274\200\347\200\200\347\210\200\346\274\200\346\214\200", 0x869566c) = -1 ENOENT (No such file or directory)
Any ideas?
Thanks,
Jayen
When you cross-compile, it means you create a binary that will run on a different architecture from what you compiled it on. In your case, this means you've used your i686 machine to build a binary that's supposed to run on geode architecture. Your app is finding the Qt libraries on your computer and that is why it runs. However, when Qt built your app, it converted some code to be geode specific, thus it's not "really" working.
If you tried this with a non-Qt app, you'd get an error when you tried to run this.
To test out your cross-compiled app, you'll have to run it inside Qemu that supports geode arch. OpenEmebedded usually provides a Qemu target. Check the available targets for geode, there should be one for Qemu. Once you've done that, you can include your app to be part of the Qemu image that get's generated, or copy it over yourself into the Qemu image, and then you can run it.
The problem turned out to be that when I compiled qt, because I had already compiled libiconv, qt was using that, instead of gconv (iconv in glibc). When I went to run it, it was using the cross-compiled libiconv, so I'm still not sure why it didn't work.
Wiping my cross-compile clean, and compiling qt without libiconv worked just fine.
I've since managed to get this running on a x86_64 host as well.
I'm a .NET CF developer trying to move to QT/CE. I'm trying to port one of my app written in .NET CF to QT/CE targeted run on Windows Embedded CE 6.0 GPS made by China. I don't have access to original SDK (china manufacturers don't provide them) so, as QT mailing lists suggested, I used Windows CE 5.0 Standard SDK as my option.
Here is my config
configure -platform win32-msvc2008 -xplatform wince50standard-armv4i-msvc2008 -release -static -fast -nomake docs -nomake demos -nomake examples
The QT compilation process goes well, I created new project in VS2008 and tried to run it on the device but I faced an error in VS "Error Unable to Start Program. Cannot find..."
I go to device's Program Files and I can see the project folder and inside it, I can see, project.exe and msvcr90.dll. However, when I double-click project.exe nothing happens. I right clicked the project.exe and select open, nothing happens.
Could anyone help me what's going on with my problems?
The fact that you have msvcrt90.dll in there is a big red flag. That's the desktop C runtimes, which indicates to me that you're probably building against some desktop SDK or that somehow the desktop runtimes and dependencies are getting sucked in.
Did you run depends.exe against the output binary to see what's actually coming out the end of the sausage factory?