> > Jason H spaketh: > I think if we could lock the lib and exe to specific versions (like Windows > SxS) > we'd be better off. We just need a way to link to specific versions of the > Qt > libraries. (Though SxS is still problematic, I think it is an improvement) > > Craig S respondeth:
> You technically already have what you need with the current releases. The > major part of the version is also part of the library name that applications > link to (or should link to!). Under Mac and linux, binaries link to > llibQtCore.4.dylib and ibQtCore.so.4 respectively. Under Windows, the major > version is made part of the library name itself rather than as part of the > extension (ie QtCore4.dll) so you have no choice but to link against a > specifc major version. Thus, there is already the mechanism required for an > application to link to specific binary compatible levels of Qt. > > <snip, good overview of major/minor versioning, binary compatibility, and > release cycle> 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'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). Yes, LGPL applications would still need dynamic linking, so I concede that doesn't address the problem from that standpoint. Anybody out there shipping with statically-linked Qt? --charley
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
