Danek Duvall wrote: > On Thu, Nov 29, 2007 at 12:56:15PM -0500, Stefan Teleman wrote:
> 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. yes, and -z nodefaultlib -B group takes care of that. If the application has the correct RPATH [ /usr/qt4/4.3.2/lib ], and has been built with -Y P,<bla> -i -z nodefaultlib -B group, all the runtime dependencies must be satisfied from the RPATH. This means that the default RUNPATH loader search is preempted. We guarantee that whatever is in /usr/qt4/4.3.2/lib (or some other version) *works correctly* for that directory location. Now if someone happens to set their LD_LIBRARY_PATH to something which happens to contain QT4 SONAMES identical to those in /usr/qt4/4.3.2/lib, but are incompatible, well, they messed-up. Sorry, LD_LIBRARY_PATH is EVIL, and they should have known that. > Google Earth and Skype I've heard of, and believe they're closed source. > The rest ... does Disney really distribute an application for Linux? No, they use it internally for their movies (Disney of Lucasfilm). The issue here is not restricted to whether or not there is distributable software available based on QT. There may be, or there may not be. I'd love to be able to run Google Earth on Solaris. The most important value to me is: If It's There, They Will Use It. Ultimately, it doesn't matter if Disney (or whomever else) make their software available for others to use. What matters to me is: why should Disney or Google only look at Linux, and not Solaris, just because Linux comes with QT out-of-the-box, and Solaris doesn't ? That's a pretty lame reason, and we can fix it right now. > 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? QT4 is compatible within Micro. It breaks at Minor. So, we really only have to maintain one of each Micro, and that only for the lifetime of the Minor. > 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? Yes. Set the RPATH correctly, pass -Y P,<bla> -i -z nodefaultlib -B group, don't set LD_LIBRARY_PATH, spend an extra 30 minutes checking the Makefiles, read the documentation we'll provide about how to correctly build software against QT4 in Solaris, check the arguments passed to the compilers and to the linker, and it works. > 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. We can't be faulted for discontinuing support for a version of QT which is EOL and no longer supported at Trolltech. Ultimately, Trolltech calls the shots on the lifetime of their software. Unless the customer in question *must must must* use this Obsolete version, and only this version, and no other version will do. In which case, both Trolltech and Sun Microsystems, Inc. should be able to make "Special Arrangements" for ongoing support of Obsolete software. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
