On 10/17/2013 3:33 PM, Alan W. Irwin wrote: > This is part 2 of my response concerning the overlinked libraries > that rpmlint has turned up: > > On 2013-10-16 20:42-0600 Orion Poplawski wrote: > >> [out of order] These libraries are unnecessarily linked with the >> specified library. > > I started to reply in detail showing the ldd --unused results, for a > number of these libraries, but in > all cases where that command differed from your results with rpmlint, > ldd had indicated a library was unnnecessarily linked which actually > (according to nm --undefined-only) had to be linked. That is, there > were man ldd --unused false positives. So here I am going to > ignore the results from that command, and concentrate on the > rpmlint results, what make VERBOSE=1 says is actually linked, > and nm --undefined-only results to attempt to confirm the > rpmlint results. > > >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libm.so.6 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libgcc_s.so.1 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotf95d.so.10.0.0 /lib64/libquadmath.so.0 > > These are not brought in by CMake directly. Instead, they are the > result of using the gfortran command to link (which is necessary > because that brings in libraries that are needed). > > So unless Debian and Fedora change gfortran, rpmlint > will continue to signal overlinking issues for > libplplotf95d which should be ignored. > > ==> nothing to do here at the PLplot level.
Agreed. >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libm.so.6 >> plplot-libs.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotcxxd.so.11.0.0 /lib64/libgcc_s.so.1 > > These are not brought in by CMake directly. Instead, they are the > result of using the g++ command to link (which is necessary > because that brings in libraries that are needed). > > So unless Debian and Fedora change g++, rpmlint > will continue to signal overlinking issues for > libplplotcxxd which should be ignored. > > ==> nothing to do here at the PLplot level. Agreed. >> plplot-qt.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotqtd.so.1.0.0 /lib64/libQtXml.so.4 > > I presume libQtXml is explicitly linked in because we > use the CMake find(Qt4) command without any components > specified. It is possible to use that command with > explicit components, e.g., > > find(Qt4 QtCore QtGui QtXml) or > find(Qt4 QtCore QtGui) > > But I haven't tried that because I am positive dropping QtXml would be > a disaster for the svgqt device whose file format is XML, after all. > > In other words, I am virtually positive that libQtXml is an rmplint > false positive. Funny thing about library linkage - only if the plplotqtd code calls the QtXml library *directly* does it need to link to it. So I'm still not completely convinced. And the actual way to disable QtXml would normally be to set QT_USE_QTXML 0. However - the FindQt4 module enforces the linkage to QtXml if QtSvg is used, so it isn't a plplot issue. If I hack up cmake's UseQt4 to drop the QtXml dep everything still compiles and runs fine. >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libSM.so.6 >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libICE.so.6 >> plplot-tk.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplottcltkd.so.10.0.0 /lib64/libXext.so.6 > > These three overlinking issues have been fixed > as of revision 12603. Thanks. >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libfreetype.so.6 >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libm.so.6 >> plplot-wxGTK.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libplplotwxwidgetsd.so.0.0.0 /lib64/libpthread.so.0 > > I think these are likely real overlinking issues, but I am going to > put off dealing with these because the on-going discussions on this > list about how we might change the interface between PLplot and > wxwidgets might result in a substantially simplified implementation > that which might reduce or elminate some of the > overlinking issues above. > ########### Makes sense. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane [email protected] Boulder, CO 80301 http://www.nwra.com ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
