I'm trying to run a Qt d-bus example (chat) on Windows. It compiles fine but I get this error:
Cannot connect to the D-Bus session bus. Please check your system
settings and try again. QEventDispatcherWin32::wakeUp: Failed to post
a message
I installed D-Bus on Windows through a ready made installer found in Google archives.
Can someone give me an idea how to run dbus-daemon on Windows?
Related
Is it possible to run a remote debug session targeting Windows with CLion?
The docs say that I can do any system that has gdbserver:
Remote OS: any supporting gdbserver and SSH
However, when I try to run my remote app, I get an error:
10:53 PM Build finished in 3 sec, 44 ms
10:53 PM Error running 'remote'
1: 'env' is not recognized as an internal or external command,
operable program or batch file.
I can't find a place where I could see the whole command that CLion runs that causes this error.
Here is my configuration:
After some investigation, I have come to the conclusion that it is impossible to remote debug a Windows app with CLion 2021.3.1 (regardless of Host platform).
CLion does not support remote debugging when targeting Windows OS using GDB Server (hence targeting Windows is impossible) due to:
CLion does not handle cases when SSH Server is using a non-Unix shell like CMD.exe or PowerShell. Commands like exec, env, chmod can’t be handled. This can be circumvented by using a Unix shell:
a. Unfortunately, connection fails for MSYS2 Bash and Git Bash when Windows OpenSSH Server is configured to use one as a default shell.
b. Windows WSL SSH Server works. Connection is established, Unix commands are recognized. WSL must be installed. It is not easy to configure WSL when Windows itself is running on virtual machine.
c. MinGW64 SSH Server. Didn’t test it.
Uploading binaries via SFTP fails when OpenSSH Service is used. Can be circumvented with 1.b..
CLion doesn’t consider the binary’s file extension. It always assumes that the binary is built for Linux, hence the attempt to transfer fails, when a binary has an .exe extension (fails to find test, though test.exe was built). This is a major bug that prevents remote debugging targeting Windows. There are, however, ways to work around:
a. Manual renaming before running debug. Unacceptable.
b. Adding a conditional custom CMake command. May work but pollutes the CMakeLists.txt
CLion can’t connect to MinGW GDB Server it has started. Connection times out. However, if the Server was started from a terminal, CLion connects successfully and is able to run debug as intended. This can ONLY be worked around MANUALLY:
a. In Edit Configurations… one must put a stub command in GDB Server:, for example ‘sleep’. In GDB Server args: ‘5’. This will give a time to manually run the gdbserver.exe command via an SSH connection in Terminal.
These issues were reproduced for CLion versions for Windows 10 and Ubuntu 20.04.
3. and 4. are very serious and prevent from remote debugging targeting Windows as it was intended to be done.
This happens when CLion connects to the Server it has started:
This is a work around:
As can be seen from the screenshots, with this approach GDB’s console does not catch the output. You must switch to Terminal to see it.
I've been setting up remote debugging for an embedded Linux target. I've tested that I have the correct combination of gdbserver running on the target and gdb client running on my workstation. I can start the server and on the workstation side run:
(gdb) target remote 10.28.22.226:2345
and I can list source and step just fine.
In Qt Creator I have configured a device. In that window I specify the GDB server executable: gdbserver (see pic).
I also configure the cross debugger in the 'Build & Run' Debuggers tab as shown below:
In this case, I have manually started the gdbserver with my executable on the target with port 2345. To start debugging with Qt Creator, I choose the Debug->Start Debugging->Attach to running Debug server pulldown menu. It gives me the prompt shown below, where I enter the server port (2345). I give it the appropriate kit and local executable (copy of the executable on the remote target).
After I hit OK, it seems to run the gdb client locally with a few commands, then times out trying to communicate with the gdbserver. I have debug logging turned on with the server, so I know the server never sees anything from the client run from Qt Creator. Additionally, I did Window->Views->Debugger Log to help me get a better idea of what was going on. The log shows the correct IP address and port for my device, but I don't see anything that looks like a 'target remote IP:port' call.
I'm looking for a hint or reference here. I seem to be a bit stuck at the moment. Thanks!
EDIT: additional information - I've verified that my gdb client has support for python compiled in. I see that Qt Creator requires python support. I also have further support that nothing ever goes out on the wire from Qt Creator. I did a wireshark capture and don't see anything going to port 2345 on the target.
Alternately, if anyone would share their Qt Creator debugger-log output with me so I can compare, that would be helpful.
Avoid Qt Creator 4.5-beta1. It seems 4.5RC1 doesn't have this problem. I was able to do remote debugging using the method described above just fine.
Even QtCreator 4.5.0 seems to have the same bug.
The only workaround I've found is to start the GDB server manually on the remote target: with "top" I get the pid of the remote process to debug then I run the following command: gdbserver --attach remote ip:remote port pid.
After the server is listening, I finally choose: "Attach to Running Debug" server".
Maybe you can write a server start script on target which include the above statement...
I have set up a jenkins slave server with cygwin and I'm launching builds on it via ssh.
The build of our project succeeds if run locally as the slave user both in the windows command prompt and in the cygwin command prompt. I can also ssh into the machine as the slave user and run the build successfully.
However, when jenkins runs the build as that slave, it fails trying to compile the first C++ project with the error: fatal error C1902: Program database manager mismatch; please check your installation.
Visual C++ 2010 express, and Visual C# 2010 express are both installed and required for our project to build.
In my research I found some indications that cygwin does not handle the remote login correctly here: https://java.net/projects/hudson/lists/users/archive/2008-10/message/130
Has anyone else solved this problem?
Try below solution
Use “Launch slave agents via Java Web Start” to add windows slave to jenkins master.
It will launch Jenkins service on windows machine using some local users account. Then change local user to the user you are using to build locally.
The problem with “Launch slave agents on Unix machines as SSH” method is, it runs connection using “cyg_server” user.
This question corresponds to this QtWebSockets implementation.
I am trying to include websockets server functionality in a bigger qt-based project.
I have cloned the repo above and built the library as well as the example applications (release mode). Among the examples there is an echoserver and an echoclient. After built i start the echoserver, which seems to be successful (on terminal i see: Echoserver listening on port 1234). Then i start the echoclient, which exits immediately (no printout on the console). The server console does not show any signs of detecting connection attempts. The server listens on 0.0.0.0:1234 (checked with netstat). The client tries to connect on "ws://localhost:1234/".
I modified the echoclient example to connect to echo.websocket.org and rebuilt it. After starting the client it connects successfully and the sent message is echoed back.
I created a simple html file with a websocket client trying to connect to the echoserver and opened it with a browser. This again cannot connect to the server (works with echo.websocket.org).
Environment:
Ubuntu 13.10(64bit) running as a virtualbox guest on a win7 machine.
Qt5.2(64bit)
I thought that this is something to do with the virtualbox networking settings, so i repeated the whole thing above on the host OS (win7, 64bit). I get the same results.
Br,
Szabolcs
This problem does not happen in Qt 5.4 anymore. According to the comments above it was a bug in Qt and it seems to be fixed now, because in my environment the echoserver and echoclient work just fine.
My Environment:
Ubuntu 14.04(64bit) running as a virtualbox guest on a win7 machine.
Qt5.4(32bit)
Therefore I propose to mark this question as answered.
My application in working fine in Samsung BADA simulator but not working in device. My application is for S8500, available for download https://sourceforge.net/projects/wavechm/ with source code. I don't know what to do now?
please see the video of application how it is behaving. I have no idea what to do next. It is open source project and I do lot of hardwork and getting no result.
http://developer.bada.com/badaforum/board/thread/view.do?boardName=ide-sdk&messageId=24162&frm=1
I tried to run this app on phone
6,0,0,1,2011-05-13,02:10:27.578,1|5
Transfer completed.
The "COM5" port is closed.
The "COM5" port is open.
Command message: [1600:1601]EnableDiagWrite
Command message: [1600:1601]TerminateProcessEx feu46uenau 0
Command message: [1600:1601]AppPkgInstall /Osp/Applications/feu46uenau
Command message: [0:2]MID_PROCESSMGR,0xFF
3,0,0,1,2011-05-13,02:10:29.421,00004|10:47:85|PHONESTATUS:04> app installed, errType=0
Installation completed.
2,0,0,1,2011-05-13,02:10:29.421,Info, Installation completed.
The "COM5" port is closed.
6,0,0,1,2011-05-13,02:10:31.953,2|1|5
2,0,0,1,2011-05-13,02:10:37.406,0072.217,EXCEPTION,P28,T00,A119,Osp::Ui::Controls::Popup::Show (689) > [E_SYSTEM] Unable to show itself.
The "COM6" port is closed.
It is short log. App crashed and broke os too. (didn't stop in IDE)
Let me know which details you need. I try to help.