----- Original Message ---- > From: "[email protected]" <[email protected]> > 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 h > ave 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 the various linker options to add the 'lib' directory in your program path to the binary's search. We install Qt to /usr/local/TrollTech/Qt-<version> on our systems and link specifically against that path. No editing LD_LIBRARY_PATH on Linux. On Windows, you can do the same thing though we just drop the DLLs in parallel to the executable as you don't typically put the application path in the PATH anymore, just drop a shortcut on the desktop - and in that respect the shortcut could have an alternate working path too to achieve the same effect. All I'm saying is, there are multiple ways to tackle the issue without having to revert to static/convenience libraries. Ben _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
