On 2015-05-18 17:04-0600 Orion Poplawski wrote:

> On 05/17/2015 02:02 AM, Alan W. Irwin wrote:
>> Hi Orion:
>>
>> In the last month or so you brought a number of linking issues for
>> the traditional build system to my attention.  I believe
>> commit id = 6a5bad5 should fix those.
>>
>> Would you please run your traditional build tests on Fedora again to
>> check that?
>>
>> Once you confirm all is well (i.e., no overlinking or underlinking)
>> with the traditional build for this change, then I plan to deal with
>> some of the other issues you brought up that did not involve the
>> traditional build system.
>>
>> Alan
>
> I suspect that some of these are unnecessary:
>
> plplot-ada.pc:Libs: -L"${libdir}" -lplplotada  -lplplot
>
> Removing -lplplot still allows the ada examples to compile.

Actually, that underlinks some of the examples (such as example 15) which have 
callbacks in
them which are implemented in Ada with direct calls to the C library
routines, e.g,

software@raven> nm --undefined examples/ada/x15a.o |grep c_
                  U c_plfill

and similarly for the other Ada examples with callbacks.

Here is the comment (in bindings/ada/CMakeLists.txt) from the CMake perspective:

   # N.B. nm evidence shows that examples that use
   # callbacks (e.g., plfill in x15a.adb) have unresolved references
   # to c_plfill, etc. that require a public link to plplot
   # regardless of how NON_TRANSITIVE is set.
   target_link_libraries(plplotada PUBLIC plplot)

So I have just followed that CMake linking model for the traditional build
as well.  Of course, I am no linking guru so if somebody here can give
convincing reasons why that CMake linking model is incorrect (i.e.,
reasons why I should ignore the above undefined reference to the C
version of the callback), then I would change both that model and the
pkg-config version of that model.

>
> plplot-qt.pc:Libs: -L"${libdir}" -lplplotqt  -L"/usr/lib64" -lQtSvg
> -L"/usr/lib64" -lQtGui -L"/usr/lib64" -lQtCore
>
> Interesting mix of -L"${libdir" and -L"/usr/lib64", but I suspect that comes
> from the Qt stuff.

Exactly.  So if you change your architecture the locations provided by
Qt should change consistently with how libdir changes.

> Otherwise looks much better, thanks!

And thank you for bringing up this topic.  Our traditional build is a
whole lot stronger now as a result.  See, for example, Arjen's recent
almost complete good test of the traditional build on Cygwin which has
never gotten as far before.  So this is a nice example of the RedHat
Fedora community indirectly helping the RedHat Cygwin community, and
vice versa because some of the recent Cygwin PLplot fixes are general
ones that help all the Linux distros.  After all these years, I still
like this cooperative development model the best.

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
__________________________

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to