On 2011-11-23 17:48-0700 Orion Poplawski wrote:
Hi Orion:
Thanks for those tests.
Let's start with C++ to try and understand what is
going on in that case.
>
> /usr/lib/ccache/c++ x17.cc -o x17 `pkg-config --cflags --libs plplotd-c++`
> /usr/bin/ld: /tmp/ccUpkDBH.o: undefined reference to symbol 'c_plrandd'
> /usr/bin/ld: note: 'c_plrandd' is defined in DSO /usr/lib/libplplotd.so.11 so
> try adding it to the linker command line
> /usr/lib/libplplotd.so.11: could not read symbols: Invalid operation
>
Here is what plplotd-c++.pc looks like on my system with your
Requires.private change.
libdir=/home/software/plplot_svn/installcmake/lib
includedir=/home/software/plplot_svn/installcmake/include/plplot
drvdir=/home/software/plplot_svn/installcmake/lib/plplot5.9.9/driversd
Name: PLplot C++
Description: Scientific plotting library (C++ bindings, double precision)
Requires.private: plplotd
Version: 5.9.9
Libs: -L${libdir} -lplplotcxxd
Cflags: -I${includedir}
So libdir and includedir are fine, and the assumption (for shared
libraries that ignore Requires.private) is that all symbols in the
C++ examples will be resolved by libplplotcxxd. That assumption
should normally be correct, but it is violated by c++/x17.cc which
has the following line:
noise = plrandd() - 0.5;
which refers directly to our C API rather than the correct C++
wrapper function:
noise = pls->randd() - 0.5;
In other words, we haven't been as careful as we should with the C++
examples to replace the C API with the C++ API, and your test caught that.
However, since you didn't get any errors prior to example 17 it
appears we are doing exactly the right thing for the C++ case from the
pkg-config Requires.private: perspective (and also from the CMake drop
transative linking perspective). (Of course, this conclusion is
subject to removing this example 17 error and any other similar errorr
in the C++ examples after example 17.)
Unlike C++, the other languages do not allow arbitrary mixing of C API
into their examples so probably whatever is wrong in those cases is
due to a variety of issues. Nevertheless, the good results you have
found for most C++ examples (and the simple explanation of the C++
error you found for one of the examples) are encouraging and probably
mean the basic approach is correct. That means we can probably
continue with moving to Requires.private: for pkg-config and dropping
transitive linking for CMake languages subject to tracking down the
origin of the errors you found for other languages.
> So I think it is probably worth it to keep plplotd in the Requires, but
> perhaps move the others items out of the plplotd.pc Requires.
I suggest not doing that since I would far prefer to have our C++
users encouraged to use just our C++ API by our cmake and traditional
Makefile+pkg-config build systems for the installed examples.
Here are my further plans:
Implement the NON_TRANSITIVE option for our build system that will
drop transitive linking for the CMake case and replace Requires: by
Requires.private: for the pkg-config case. This option will be
experimental and will default to OFF. Then I plan to go through our
languages (starting with C++) one by one to deal with all the various
issues that are found with turning that option ON.
Orion, could you answer the question that occurred by one of the
posters in the "transitive linking topics" thread on the CMake list
about why rpmlint is complaining about this "formal" overlinking
issue? I responded at the time by some speculation that it has to do
with eliminating unnecessary package dependencies, but it would be
nice if you could follow up (there if still subscribed or here,
otherwise) with the definitive answer.
Same question to Andrew about the complaints about overlinking from
the Debian packaging software.
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
__________________________
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
