From: Alan W. I. <ir...@be...> - 2013-10-17 21:33:46
|
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. > 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. > 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. ==> nothing to do here. > 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. > 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. ########### This is the end of part 2. Later today I hope to respond to the rest of your e-mail for part 3. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ |