On 2009-03-14 19:11-0000 Andrew Ross wrote: > On Fri, Mar 13, 2009 at 04:45:45PM -0700, Alan Irwin wrote: >> Hi Andrew: >> >> I frankly don't understand the differing results that we had, and that >> bothers me. In particular I don't understand why you had memory management >> problems for the versions prior to your recent commit while I did not (either >> reported as segfaults or valgrind memory management issues) with >> Debian Lenny. To further document what I have installed on my Debian Lenny >> 64-bit hardware (i.e., amd64) system the cmake output results relevant to qt >> are >> >> -- Found Qt-Version 4.4.3 >> >> Do you get the same Qt version number there? > > I don't because I still have the default cmake 2.6.0 installed on the > Debian system. ldd shows that qt.so is linked against the Qt4 libraries > and the installed version is 4.4.3.
OK, but execution of the cmake application (regardless of whether for CMake version 2.6.0 or 2.6.3) should output the Qt version number as above. Also, note that for a while now I have been running cmake-2.6.0 (my own built version rather than Debian's) to make sure my testing is done with a virtually identical build system to yours (and also to keep testing against our minimum version of CMake to insure nothing creeps in that will not work on that version). So it appears to me that between us we had a virtually identical build system, same library set (at least for your Debian Lenny test), and same 64-bit hardware, but with the puzzling result that we got quite different qt results until your fix. Here is another speculation about what might have been causing the memory management problems for you. Such issues can be caused by inconsistency in your Qt-base library installation. For example, until I fixed the rpath problems (see below) I was getting segfaults with my attempt to use qt devices in the install tree. The CMake documentation implies qmake provides the compilation and linking information for Qt4. Do you have a consistent version of that? Here are the (consistent) results I get for that question for my system Qt4 libraries: softw...@raven> /usr/sbin/update-alternatives --list qmake /usr/bin/qmake-qt4 > I suspect the issue is due to the fact that we are doing some > non-standard things with Qt. This I'm not surprised about. More worrying > is this non-reproducability, even on the same Linux distribution. I think > this needs close testing on as many versions and platforms as we have > access to, to reassure ourselves that it really is robust. I completely agree with your conclusion. Furthermore, we should look at any unexplained discrepancy (like the varying glyph sizes on different Linux platforms) with a microscope. I hope everyone here will participate in these much-needed tests for all accessible Linux, Mac OS X, and Windows platforms. The last two platforms probably require downloading your own version of Qt4 from http://www.qtsoftware.com/downloads/downloads#lgpl, and it turns out that download of that version for Linux also helps. I just tried that for the Linux-64-bit SDK version. Running the qt installer went well and gave me a private version of Qt-4.5. I then set up the PLplot build this way to get access to that private version: # Everything related to latest Qt from Trolltech: PATH='/home/software/qtsdk-2009.01/qt/bin:'$PATH export CMAKE_LIBRARY_PATH=/home/software/qtsdk-2009.01/qt/lib export CMAKE_INCLUDE_PATH=\ /home/software/qtsdk-2009.01/qt/include":$CMAKE_INCLUDE_PATH" (The last two exports may be overkill since the Qt4 documentation for CMake implies putting qmake on your path is all that is necessary.) As expected, the cmake run (where I enabled svgqt, see below) output the following Qt-related information verifying the Qt version: -- Found Qt-Version 4.5.0 After the PLplot build, I also verified with ldd -r that drivers/qt.so in the build tree pointed to the correct (private) versions of the libraries. Before revision 9738 where I fixed the issue, there was a build-system screwup with rpath for the installed version with the net result that ldd -r showed that $prefix/lib/version was pointing to the wrong (system version) of the Qt libraries.so which produced segfaults when I attempted to use any qt-related device in the install tree. (See comments above about how easy it is to produce segfaults for inconsistent qt library versions.) After revision 9738, all install-tree tests went fine with Qt-4.5.0 (except for the 50 per cent sized glyphs for -dev qtwidget and the 80 per cent sized glyphs for all other qt-related devices). I didn't see any offset issues, but there might be some subtle shifts I will see once the glyph size problem is fixed. Note, the tested devices included -dev svgqt which I have re-enabled again (revision 9737) by default for the reasons below. Under both konqueror and firefox (the versions of which I have given before) those svgqt results look identical to the pngqt results, i.e., the text offset issues that you see with Qt-4.4.3 and SVG output seem to be gone with Qt-4.5.0. That's a most gratifying improvement in Qt4's SVG treatment. Also, I looked more closely at the validation errors I was bitching about, and the only problem appears to be the w3c validator only deals with SVG-1.0 and 1.1, and Qt actually produces SVG-1.2 (a w3c draft standard which documents the attribute that the validator was complaining about). My conclusion is that the Qt4 SVG-1.2 file results will validate once the w3c validator gets up to speed with SVG-1.2. To summarize all of these various but related topics: * Qt has a rather complex set of libraries so that memory management issues can be triggered by something as seemingly innocuous as an inconsistent qmake version or bad rpath. * The preliminary results for the qt devices are looking good (aside from the glyph size issues I am encountering regardless of Qt library version). * The build of PLplot with the latest Qt-4.5 is straightforward and worth the effort. * For example, Glyph offset issues for Qt-4.4.3 seem to have been addressed for Qt-4.5.0 (at least for SVG if you use a reliable SVG viewer like firefox and probably the other devices as well). * The SVG validation errors I encountered before for svgqt have been completely explained and are basically not an issue. * We need testing help (using Qt-4.5.0) on all platforms to figure out the obvious remaining issue (inconsistent glyph sizes) and also to verify that all the memory management issues are now gone. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
