On Sun, May 10, 2009 at 08:42:56AM -0700, Alan Irwin wrote: > On 2009-05-10 11:38+0100 Andrew Ross wrote: > > >> I don't completely trust QT_LIBRARIES_optimized because it appears to be > >> incomplete (see above discussion). However, I have checked with "ldd -r > >> qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on > >> Linux without any undefined variables for the downloadable Qt-4.5.1 > >> available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not > >> have > >> some of the missing libraries, they show up in ldd anyway (which is why > >> there is no undefined symbols). So I am going to leave in this "Release" > >> possibility for now. But if there are problems with > >> -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I > >> think is a bug in FindQt4.cmake), then I will only use > >> QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug > >> subset and the QT_LIBRARIES_general subset are empty. > > > > Alan, I agree with your analysis, although I hadn't noticed the bug you > > mention which leads to multiple libraries listed after a single debug tag. > > I must admit that all I looked at was the qt_LIB_DEPENDS in CMakeCache.txt > > where all the non-QT libraries are marked as general. Do you see this as > > well? > > If so, then I suspect that cmake treats any library without a tag as a > > general > > option. If the general tag is not explicitly used at this stage it would > > explain > > why > > The only relevant variable here is QT_LIBRARIES since that is what we > (indirectly) use to generate the plplotd-qt.pc result. cmake now > prints out QT_LIBRARIES (both before and after processing) so you can see > exactly what is happening. > > > > > 1) everything just "works" for the general case without any explicit removal > > of the general tag. > > There is never a general keyword in QT_LIBRARIES. > > Here is the full list (taken from cmake output) > I get if CMAKE_BUILD_TYPE is specified > > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl > > I have put in some carriage returns to make the result clearer, but I have > kept the existing order (unlike the previous time I gave these results where > I reordered them). > > Note the pattern is optimized followed by one library, debug followed by > that same library, then the dependent libraries (if they exist for that > library) which are counted as debug because of there position in the list. > This pattern repeats for each general kind of Qt library. Note, > /usr/lib/libSM.so is the first dependent library. > > If CMAKE_BUILD_TYPE is not specified I get the above results with the > optimized stanzas dropped, and the debug keywords dropped (and no general > keyword applied). In this case, the dependent libraries are classified as > unkeyworded. > > These results seem exactly consistent with my analysis. Do you confirm these > results on your own system with and without CMAKE_BUILD_TYPE being > specified?
I do, but my interpretation of the libraries after the debug is different to yours. I think the debug tag only applies to the first. The subsequent ones are untagged and therefore should be considered to apply to both optimized and debug. This would mean there was no bug. It's also consistent with how cmake seems to treat the libraries. In this case my original patch would work correctly. I need to delve deeper into the FindQt4.cmake to see if this is true. Andrew ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
