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
__________________________

------------------------------------------------------------------------------
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=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to