[Qt5-feedback] Qt major versions (was: C++ api to use for UI in addition to QML)

[Craig.Scott at csiro.au]

On 25/05/2011, at 10:39 PM, Charley Bay wrote:

> What about out-of-the-box support for static library linking?  While not perfect for every application, large desktop applications like Maya could simply statically-link the required Qt version, and never suffer the "anomalies" of system Qt library upgrade.

I have some sympathy for you with regard to Maya (we also develop plugins for Maya). Even if Maya statically linked its own Qt libraries, that wouldn't really help you. To be able to pass Qt objects (QWidget, etc.) between your plugin and Maya itself, you would need a shared Qt between the two (see below for why).


> I've built-and-statically-linked Qt, but IMHO it would be nice if the static libs were a first-class deployment option (e.g., automatically available when Qt is installed, I'm a commercial customer).

We've found that rather than statically linking to Qt, it is better for us to ship our own Qt libraries with our applications and to use launch scripts/apps that modify environment variables before launching the real binary. For example, we put only launchers in the bin/ directory and we put the real binaries in lib/, and the launchers add the lib/ directory to the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac - with mods for frameworks too). Since the environment variables are only augmented when the launcher runs and the modifications only apply to the process and not system-wide, the changes made don't affect anything else in the system other than the specific binaries in your package that you want to use them on. One advantage of this is that you don't need to worry about what Qt libraries are installed on the system. Another is that if you want to make your application available on the system path, you can add your bin/ directory to the PATH and not have to modify the system LD_LIBRARY_PATH or anything like that. You also avoid the situation where your own Qt libraries might interfere with the system ones (and I've had to work around packages that unfortunately do this when they put their bin/directory on the PATH under Windows but they also put their Qt libraries in there). By using the launchers approach, you can make your executables available to the users system-wide, but you don't have to pollute the system's library paths or be affected by the system's Qt libraries (if present). We also make our launchers augment QT_PLUGIN_PATH plus a few other app-specific things, but you get the idea (hopefully!). Note that this works across all platforms, but it only works if you can control the way apps are launched. Thus, this won't work for Maya or other situations where you are only supplying libraries or plugins for other packages.

There is also a hidden danger with using statically linked Qt when you are talking about mixing two binaries where each has separately linked to their own static Qt libraries. As an example, consider if Maya was built with static Qt libraries and then you built your own plugin for it and you linked your plugin against static Qt libraries too. Even if both used the same Qt version, the problem here is that each ends up with its own copy of static data. Now, if Qt uses any singletons or static data anywhere, even internally (ie not part of the public interface), you might end up with situations that violate assumptions the Qt code may have reasonably made. For instance, if Qt maintained an internal list of things it had allocated, there would be two lists - one in Maya and one in your plugin. If you now passed an object created in your plugin through to Maya and the Qt code in the Maya binary tried to find that object in its own internal list, it would not find it and may assert. I don't have any specific cases I'm aware of where Qt code would be vulnerable to this, but I'd be very surprised if there weren't such instances. Note that this would not be a bug in Qt, it would be a mis-use of Qt.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia