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

[Charley Bay]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110525/1a9b8c91/attachment.html