On Thu, Nov 29, 2007 at 12:56:15PM -0500, Stefan Teleman wrote:
> It becomes dll hell if the headers and shared libs are exposed in default
> search paths, either for headers or for shared libraries. If QT4 lives
> under /usr/qt4/[version]/{bin,lib,include,share} and no symlinks to default
> search paths exist [ which is what i am proposing here ], it becomes a
> matter of setting the correct RPATH, the correct -I, the correct QTDIR and
> -Y P,<bla> -i -z nodefaultlib at compile and link time.
It's DLL hell whenever you can get in the situation where an executable
ends up with the images of two different versions of the same library in
memory -- generally by directly linking with with the library as well as
with another library which brings in the second copy. It really doesn't
matter where the libraries are on the system, or how hard it is to compile
against them; once a binary is compiled, it's going to link against what
it's been told to link against.
>> Are there enough QT-based applications which can't simply be rebuilt to
>> use whatever version of QT is on the system to really require all the
>> libraries?
>
> There is enough software based on QT which makes this answer: it's up to
> the software vendor if they want to change QT versions. They may not want
> to, in which case they will choose one of the following two alternatives:
>
> - give up on Solaris -- most likely to happen. Why would Lucasfilm,
> Synopsys, Google Earth, Skype, NASA or Disney be interested in the business
> of supporting QT on Solaris. Linux already comes with QT.
Google Earth and Skype I've heard of, and believe they're closed source.
The rest ... does Disney really distribute an application for Linux? Does
Lucasfilm? I could see them having internal software, but then they can
recompile, or at least require that the version of QT available on the
system never change until they're ready to do so.
Is QT4 source incompatible from dot-release to dot-release? That is, does
Google need to use the same version of QT for all the platforms where they
use it for a given app?
> - deliver their own QT for their Solaris software. Unlikely to happen.
Sure.
Do the direct binding tricks that help with this problem for C libraries
work for C++? Would they help for QT?
>> Alternately, would it make sense to have only one version of the QT
>> binaries, headers, and .so links, and have all other versions on the
>> system be only libraries which other binaries may have already linked
>> against?
>
> Binary incompatible changes can happen via changes to header files only,
> and not necessarily only through C++ translation units.
Of course. But I'm talking about a situation where you'd only develop
against the latest version of QT, but apps linked against older versions
would be able to run because the loader would still be able to find the
libraries. Is that a scenario that would work?
> Let's make a clear decision about how many different versions of QT4 we
> allow to coexist at the same time, and for how long, what is the sunset
> policy, and stick to it. It only requires some coordination with Trolltech.
> They don't support their Minor.Micro releases forever either.
They have different responsibilities than we do, and I think looking at it
from the perspective of the developers who build against QT and the popular
apps which link against it. What are the costs of maintaining just one
version, or just one version to develop against? Since we don't control
QT, determining when to stop supporting a release should be based on how
the software is actually being used, and whether the maintenance effort
would be more painful to continue supporting it than the backlash and
sudden lack of apps would be if we stopped. From our perspective, fixing a
number of versions and a time period for each in advance seems too
arbitrary and inflexible, though some guidelines about how what would be
manageable and/or necessary would be useful to help various groups make
decisions about what they're willing to or need to include.
Danek
