Lars Knoll, Qt Project’s Chief Maintainer, blogs to let us know that Qt 5.0 beta 1 is out. Hurray! Go forth and download.
You can dowload the source code and binaries from the official Qt Project CDN. The tarballs for building on Unix systems like Linux are in the split_sources subdir — Linux distribution packagers will want to use them. Once those packages exist for distributions, they will be listed in the Qt 5 unofficial builds page.
This is the first Qt 5 release to also include installable binaries. Windows and Mac users have had them for ages in Qt 4, and Linux users have enjoyed them in the past in the form of the Qt SDK binary installers. As far as I can remember, this is the first pure Qt library release to contain Linux installers.
But, as the nature of the beast goes, those installers are known to work only on Ubuntu distributions. The main reason for that is because Qt 5 depends on the ICU libraries, whose developers went to the “OpenSSL School of Releasing” (along with the Boost developers) and haven’t learned yet to make binary-compatible releases. Sorry about that. If you don’t have the build capacity to compile the sources yourself, you may want to wait until packaged, binary builds show up for your distribution (in the form of RPMs and DEBs).
The goal of the beta, as I explained in a previous blog post release is to gather feedback on the implementation and to get bug reports. From this point on, the Qt 5 API is “soft-frozen”, meaning that it will not change incompatibly any more, except to fix major issues that we encounter or we’re told about in the form of feedback. If that happens, we’ll make sure to make a note of it in the release notes.
That means that Qt 5.0 beta1 is a suitable starting point for porting applications and writing new code. Your work will not be wasted. But you might run into bugs, so please report them to us, in the Qt Project Task Tracker. We’re also very interested in bugs related to packaging, building, the installers, documentation, etc. Just be sure to look first at the Known Issues page before reporting anything.
5 comments
Pau Garcia Quiles
August 30, 2012 at 22:54 UTC (UTC 0)
developers went to the “OpenSSL School of Releasing” (along with the Boost developers) and haven’t learned yet to make binary-compatible releases
A proprietary database we use solves this problem in an interesting way:
They only depend (DT_NEEDED) on libc
They dlopen all dependencies that you would normally link to
They dlsym every function they depend on. I’ve been told they use some kind of autogenerated wrapper (which includes workaround implementations) but I have not reached the actual guys in charge of this part.
This makes possible to develop applications which link to system libraries (for instance, libssl) and their libraries (which also link to libssl).
It’s quite a bit of work and it’s certainly not something you want to do as an app developer, but for libraries on Linux, it looks like a neat solution. It’s been working fine for them for quite some years already.
Digitalus
August 31, 2012 at 07:40 UTC (UTC 0)
What about using openSUSE Build Service for GNU/Linux binaries? It can compile packages for most major GNU/Linux distributions.
Thiago Macieira
August 31, 2012 at 11:26 UTC (UTC 0)
@Digitalus: it’s an option we’re considering, but I’m not sure of the benefit. Distributions will build packages anyway, so why should we? I’d much rather that their packagers join us and publish their RPMs and DEBs and whatnot at the same time as the source code is released.
Thiago Macieira
August 31, 2012 at 11:26 UTC (UTC 0)
@Pau: that works, but it has an overhead cost and it can’t be prelinked.
Pau Garcia Quiles
September 1, 2012 at 23:59 UTC (UTC 0)
@Thiago,
Not prelinking is not really a problem for a database daemon, which is probably only restarted a few times a year tops. A desktop application is obviously different.