Good evening,
I inherited a project made using QT creator (C++ and Qt Quick).
The target is a DaVinci DM8168 board with **Linux kernel 2.6.37 **on it.
In particular I'm using Qt Creator 4.2.0 (4.2.0)
Based on Qt 5.7.1 (GCC 4.9.1 20140922 (Red Hat 4.9.1-10), 64 bit)
I can build & run the application for the target and I can see it running.
I need to launch the profiler. But it does not work. When i run the application (on the target) using the parameter:
qmljsdebugger=port:xxxx
then the application does not start anymore!
I tried to add these options to the project's .pro file:
DEFINES '' += QMLJSDEBUGGER
DEFINES '' += QT_DECLARATIVE_DEBUG
PACKAGECONFIG_append = " qml-debug"
I, obviously, build in debug mode.
When I try to run the applicative on the target i get this message:
QML debugging is enabled. Only use this in a safe environment. Process
killed by signal
I repeat: if the option "qmljsdebugger=port:xxxx" is removed then the application starts and works properly.. but of course the profiler wouldn't connect in this case.
As I said, I've inherited the project and I'm complete new to this environment.
Any help or suggestion?
update
these are now the lines I've added to the .pro file
DEFINES '' += QMLJSDEBUGGER
DEFINES '' += QT_QML_DEBUG
CONFIG += qml_debug
I checked the various path for QT and exported PATH and LD_LIBRARY_PATH.
Unfortunately nothing changes:
If I launch my program using:
/opt/MyPrefix/MyProgram -platform eglfs
then it works.
if I use:
/opt/MyPrefix/MyProgram -qmljsdebugger=port:3456 -platform eglfs
then it crashes
QML debugging is enabled. Only use this in a safe environment.
Segmentation fault
the program seems to start in Debug Mode and this is ok. The problem is the profiler :(
ps: As far as I know there are no firewalls running on the target. I'll check better for sure.
update 2
I tryed the same solutions as above but on a simple program as suggested(an "hello world" basically) and it does not crash when the "-qmljsdebugger=port:3456" option is specified... I really don't know what the problem is in my original application.
First there are a few prerequisites to make qml debug run like being sure that Qt was built with the exact same toolchain as the binary. You should take a look at Qt Wiki: https://wiki.qt.io/How_To_Profile_QML_App_on_Embedded_Device
An important note is that how you make qml debugging works has changed between Qt Quick 1 and Qt Quick 2. As you are using Qt 5, I believe you should be using Qt Quick 2. So that means that you should not use QT_DECLARATIVE_DEBUG, but QT_QML_DEBUG.
More details: https://doc.qt.io/qt-5/qtquick-debugging.html#qml-debugging-infrastructure
If you still have issue after using the proper DEFINES and making sure that evry prerequisite was met, then you should try with a basic Qt program that does nothing, but display a simple QML item (like a Rectangle or a Button) ans see if you still have the issue.
Related
How do I cross-compile a QT application for a Freescale Hummingboard(imx6(arm))?
There are some guides around, but I've not been able to complete one with success.
The following (and more) guides give me a compile error on ./configure
http://forum.solid-run.com/linux-on-cubox-i-and-hummingboard-f8/qt5-3-on-hummingboard-t2072.html
https://community.freescale.com/docs/DOC-94066
When I run the ./configure command (With recommended commands, I've tried this with a lot of possibilities for commands but got none working). I got a compile error for all the external libraries QT uses (zlib, libjpeg, libpng, etc.). So it's a dead end from there.
I've tried a lot more stuff, I don't even remember all the stuff I've tried, but I got nothing working.
I'm trying to use mini-distribution for the Hummingboard. It's a system without window manager that is able to run QT applications (QT5). The build tool I'm trying to use is gcc-linaro-arm-linux-gnueabi, I'm using QT Creator. I've got QT working on the Hummingboard, I just can't compile anything for it.
I managed building an application for the IMX6 finally. Here is how I did it for other's. It's not an optimal solution but it is an solution.
I use Buildgear to build mini-distirbution as OS (Google it, not enough links with my reputation). I append my own application to this mini-distribution to also build it. This is done by placing creating a folder in the buildfiles/cross/cross-hummingboard folder and adding a buildfile (mine look like this http://pastebin.com/bZkJUiry). In this folder I also place a .tar of the project files (including the .pro). To get it to build I add "qt-gui" as a dependency to the fs (buildfiles/cross/cross-hummingboard/fs) by adding it to the list of depends.
I then run buildgear build fs, which will create an (Tarred) image including my (working) qt-application! I then extract the ./qt-gui executable and ssh it to the Hummingboard.
Of course this is all a bit cumbersome so I made a script that automates this all: http://pastebin.com/jFM6rZyY
It copies and Tars sources, compiles it together with the fs, extracts the executable, ssh's the file to the hummingboard and runs it. Takes about 3 minutes building but it works which is what counts for me at this point.
I've had to move my stuff from a failing hard drive, so I've had to set up and reinstall everything again. And I've run into a couple problems.
So I've got two errors here. The first error that I get is when I open flashdevelop to begin working. I get the error of:
Can't Find Haxelib.exe
And of course, I've installed haxe and haxelib and everything else that's needed pre-setup. However, when I run, the flash and html5 targets work fine regardless. I don't know why that error shows up. Any ideas?
My second problem is that I've installed the necessary stuff for the windows runtime. However, when I try to run the exe in or outside of flashdevelop, the program freezes and gives me the:
This program is not responding.
error that you sometimes see when you crash a program. However, I have my neko stuff set up and it compiles fine, it just crashes on start. I have the background set to neko. I have just a sample hello world FlxText object like this:
hello = new FlxText(0, 0, 100, "Hello World!");
#if neko
hello.color = 0xffffff;
#else
hello.color = 0xffffffff;
#end
add(hello);
Any idea what could be causing the start crashes? It also has me wondering if the two aren't related some how.
Thanks in advance!
Using windows 8, haxe, haxeflixel, windows & neko runtimes.
I had this posted on another forum. The not responding error is fixed easily by adding:
<window allow-shaders="false"/>
In the projects xml file. The haxelib error still shows but it may be a non issue.
Things to try:
Make sure you use Haxe 3 and OpenFL (I think there is no sense of using Haxe 2 or NME).
Check if Haxe on PATH is Haxe 3 and check that OpenFL work fine. (Just open "cmd" and type "haxe" there to see version of Haxe available and type "openfl" there to test if it works, also check "haxelib")
Check FlashDevelop Haxe SDK
Trace your haxelibs here(use haxelib list in cmd)
This program is not responding.
This may mean, that you don't have some .dll in bin folder.(Depending on what you use in your project).
Or this may be connected somehow with your GPU drivers. Or it can be anything other. To get more info about that crash, try compiling to neko, and print output here.
Make sure you have latest haxelibs installed (haxelib upgrade and haxelib selfupdate)
To help you I need more info, print FlashDevelop output here.
Hi I am using NVidia Nsight 2.2, have a GTS 450 card and latest drivers. Windows Vista 64 bit. When launching graphics debugger the application crashes on the very 1st drawcall. The callstack looks like this:
nvwgf2um.dll!5bdd7d53()
[Frames below may be incorrect and/or missing, no symbols loaded for nvwgf2um.dll]
nvwgf2um.dll!5be9c7f7()
nvwgf2um.dll!5bde377e()
nvwgf2um.dll!5bc02afb()
nvwgf2um.dll!5bc0257b()
nvwgf2um.dll!5bc0259e()
nvwgf2um.dll!5bdd0612()
nvwgf2um.dll!5bcb2292()
nvwgf2um.dll!5bc45072()
nvwgf2um.dll!5bcbff8c()
D3D11SDKLayers.dll!5ea52f2f()
Nvda.Graphics.Interception.100.dll!5dbb2853()
Nvda.Graphics.Interception.100.dll!5dba317e()
Nvda.Graphics.Interception.100.dll!5db99b21()
Nvda.Graphics.Interception.100.dll!5df0150f()
Otherwise it runs fine by itself, only crashes if I launch through Nsight graphics debugger.
I suspect this is somehow related to me using DX11 dynamic shader linkage. Since my other applications that don't use dynamic linkage run fine. Anybody experienced this before, or has any info on this issue with Nsight?
What driver and exact build of 2.2 are you using? (Nsight->Help->About Nsight->Build number)
The problem might be related to DX Control Panel's debug layer setting. (Please check my comments in Sebastien's answer).
I'm attempting to package Mnemosyne, an application that uses PyQt, on Mac OS Lion via Py2app.
I'm getting several errors like the following:
objc[2826]: Class QCocoaView is implemented in both
/Volumes/Bullfrog/patrick/m2/./dist/Mnemosyne.app/Contents/MacOS/../Frameworks/libQtGui.4.dylib
and /opt/local/lib/libQtGui.4.dylib. One of the two will be used.
Which one is undefined.
objc[2826]: Class QCocoaWindow is implemented in both
/Volumes/Bullfrog/patrick/m2/./dist/Mnemosyne.app/Contents/MacOS/../Frameworks/libQtGui.4.dylib
and /opt/local/lib/libQtGui.4.dylib. One of the two will be used.
Which one is undefined.
The first version of the class is the one used in Py2App and is the one that should be used (I am trying to make the app standalone). The second is the system Qt that I installed via MacPorts. What do I have to add to the application to make it use the bundled Qt and not the system Qt?
And also several statements like this:
On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded. QObject::moveToThread: Current thread
(0x10246c880) is not the object's thread (0x106985d00). Cannot move to
target thread (0x10246c880)
Honestly I don't really understand how to do what I need to do here just based on this error message (I'm not a coder; I'm just doing my best to package the software).
This article gives a solution: simply add a blank qt.conf file in the application's Content/Resources directory.
I developed an application using a recent Glade, so I need it to load the UI from XML at runtime, using the GtkBuilder. If I try to run this on a distro which has too old a Gtk (e.g. RHEL 5), it will fail like this
undefined symbol: gtk_builder_new
which is normal and expected. But I wonder if there is a way to catch that error and instead display a GUI error dialog saying something like "your version of Gtk is not new enough"? This is an error that happens before my main() starts, so really the question is, is there a way to handle runtime linking errors? While googling, I found a mention of the concept of a linker plugin but I didn't find details about that yet. It sounds like something which would have to exist outside my application anyway, so maybe that's going a bit far.
I could use dlopen() to load Gtk, but that's ridiculous because I'd have to give the full path to it, and then I'd have to call dlsym() a lot to link every function that I need. ld-linux.so does the search for me. Is there a way I can use ld-linux.so to tell me the path to libgtk without actually loading it, then I check whether the version is new enough (or just whether gtk_builder_new exists), then finish the runtime linking if it's OK?
Well, it doesn't work that way on a Linux distro. What you're basically doing is bypassing the package manager.
The good way is to build your software on the target distro. At configuration time (call to ./configure) you will see that the requirements to use your software are not met. Or if you have no configure script, the compiler will yell at link time.
Then, it's the packager's job to fill in the requirement of the package. If in the .spec file of your RPM package you require gtk >= 2.16, then at installation time, the user will be shown the dialog telling him that some dependencies are missing, and he will see that his GTK version is too old.
You seem to be talking about the situation where you have compiled against headers with a recent enough version, but are running on a system where your library is not recent enough.
GTK provides a facility for checking that you have linked against a new enough version of the library. For example, if you need at least GTK 2.12 (which is the version in which GtkBuilder was introduced) you can use this code which will even display a nice GUI error dialog:
if (gtk_major_version < 2 || gtk_minor_version < 12) {
GtkWidget *dialog = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL,
GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE,
"Your version of GTK is too old to run this program.");
gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(dialog),
"You need at least version 2.12.0; your version is %d.%d.%d.",
gtk_major_version, gtk_minor_version, gtk_micro_version);
gtk_dialog_run(GTK_DIALOG(dialog));
gtk_widget_destroy(dialog);
exit(-1);
}
Here is a workaround which might help: Rename your exe and create a bash script which calls it.
Now you can do this:
EXE=...name-of-your-real-executable...
LOG=logfile
$EXE > "$LOG" 2>&1 || {
if grep "undefined symbol: gtk_builder_new" "$LOG" ; then
... show error message ...
fi
}
[EDIT] Alternatively, you can create a really small test program which just contains a call to gtk_builder_new and run that during installation or in the test script.
That way, you don't need to check for a specific error message (which might get translated on non-English systems). If this small test program fails, you can be sure it's because of this missing symbol and nothing else.