Thank you for the hint. This seems to be the problem. For some reasons, a
couple of tools are missing from libexec/qtcreator like cmdbridge*
but also cplusplus-* (never used, so I don'T miss it), qtcreator-crash_handler
and sdktool (this doesn't hurt because we have our own
replacement). I will see why these tools are not build / deployed.
The replacement with individual ssh operations is so slow that I suggest not
providing this work-around. At least here it makes QtCreatopr
completely unusable.
Regards, Jochen
Am Montag, dem 06.10.2025 um 06:13 +0000 schrieb Eike Ziller:
> Hi,
>
> if access to the remote device(s) is slow that could be a hint that the
> "cmdbridge" is either not built or not correctly installed. The
> cmdbridge is a process that Qt Creator runs on the device for file system
> operations there. If it isn't there, Qt Creator falls back to
> individual ssh operations for each kind of access (afair).
> Do you have "cmdbridge-*" in your installed Qt Creator?
> Is it a difference between running from the build directory (which you can
> also do when using build.py), and the installed Qt Creator?
> Or you might miss the corresponding features if some dependencies like golang
> are not found automatically when you use build.py. A look at
> the CMake configure output ("The following features have been enabled" / "The
> following features have been disabled") might shed some
> light.
>
> Br, Eike
>
> > On 2. Oct 2025, at 20:22, Jochen Becher via Qt-creator
> > <[email protected]> wrote:
> >
> > Hi,
> >
> > I am running QtC 17 and QtC 18 with dockers on Ubuntu 24.04. I set up
> > docker devices for devel and runtime. I am using Qbs 3 and Qt
> > 6.8.3.
> >
> > I build QtC 17 or 18 in QtC 17 and run it from within QtC using separate
> > settings (from the host QtC). I load a pretty complex Qbs
> > project
> > with quite some C++ and QML code. It works well with both native and docker
> > kits.
> >
> > Then I run the build script that comes with QtC and install QtC from the
> > generated installer. I load the same project using the same QtC
> > settings, e.g. the devices and kits are preserved. This works well for
> > native kits. But as soon as I switch to the docker kit, QtC gets
> > unusable slow. It hangs in loading the project "forever" and even when it
> > has loaded the project after a couple of minutes it hangs in
> > the
> > "Parse QML imports" forever (waited at least 15 minutes). There is a
> > 30%-40% CPU load and it seems like a lot of docker exec commands
> > are
> > being run. The whole system is very busy in its main loop (Ubuntu asks me
> > to stop the process).
> >
> > It doesn't help if I delete the settings and the .user file and start from
> > scratch. Same issue.
> >
> > I wonder what can be different between running the system from QtC or from
> > the installed binary. QtC extends the LD_LIBRARY_PATH, so the
> > started QtC gets full access to my native Qt installation. The installed
> > version comes with its own Qt installation which may be
> > incomplete.
> >
> > Another difference I see: when I run the installed QtC from console, I get
> > an error message saying that some shared memory handling is
> > not
> > available. This error message comes on starting up, before I load the
> > project.
> >
> > Any idea what the reason could be or what I should test to find the issue?
> > Should I "ldd" some specific plugin to find a difference
> > between
> > loaded Qt modules or other libraries?
> >
> > Regards, Jochen
> >
> > --
> > Qt-creator mailing list
> > [email protected]
> > https://lists.qt-project.org/listinfo/qt-creator
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> 12489 Berlin, Germany
> [email protected]
> https://qt.io
>
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
>
>
--
Qt-creator mailing list
[email protected]
https://lists.qt-project.org/listinfo/qt-creator
