plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Request for comprehensive test of traditional install tree on Cygwin

[Alan W. I. <ir...@be...>]

On 2015-05-12 10:51-0000 Arjen Markus wrote:

> [...] As the comprehensive tests fail [on Cygwin] with the traditional install tree, I have turned that off.

My impression was you originally turned that off because you did not
have pkg-config installed on your Cygwin platform.  But your current
cmake.out files shows pkg-config is now installed so at least you
should be able to try a comprehensive test (with
options

--do_test_interactive no
--do_ctest no
--do_test_build_tree no
--do_test_install_tree no
--do_test_traditional_install_tree yes

) of the traditional install tree on Cygwin.  (Those "no" options are
simply there to speed up the test by dropping the interactive part and
by not duplicating what you did before.)

Your report from this run should help me to diagnose what (if
anything) is wrong with the traditional install tree on Cygwin.

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
__________________________

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

[Alan W. I. <ir...@be...>]

On 2015-05-12 10:51-0000 Arjen Markus wrote:

> I used commit c67fd667347b09bf5d3be6c0bc73de3762e59ab1 and still see
that warning. I have attached the compressed tar-ball for your
convenience.

I very much appreciate that report since it is a largely successful
test of all the recent build-system changes I have been doing.

That report shows we have a substantial improvement from your previous report since
the warnings are now reduced from 5 or so per cmake run to just one instance
that occurs immediately at the start of our top-level CMake logic.

To pursue this further, could you please try the following
mini-project?

cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
project(test_cygwin_warnings NONE)
enable_language(C)
message(STATUS "CMake version = ${CMAKE_VERSION}")
message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")

The point of this mini-project is to try and find a simple test case
that generates the spurious warning that I can pass on to the CMake
developers to help them fix that bug on Cygwin.

If the above mini-project does not generate the spurious warning, then
there is a slightly less simple test project we can try that mimics
the PLplot initial code much more closely.  However, the differences
between that more complex project and the one above should not make
any difference with regard to the spurious warning so my bet is the
above project will demonstrate that bug.

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
__________________________

Re: [Plplot-devel] Version 6?

[Hazen B. <hba...@ma...>]

This e-mail is to provide a summary of what we had discussed, please let 
me know if I left anything out. I think we had a consensus that the 
following change would be made as part of a possible version 6:

1. All API functions return error codes.


I think we also agreed on these items, which might not actually require 
a major version bump as the actual change to the API is potentially 
small / nil:

2. Thread safety.

3. Improved text handling between core and the drivers.


And there was some discussion about whether this was a good idea:

4. Core handles some text rendering.


Now I think the question is if the effort and disruption involved in (1) 
justifies making the change. I would say that I'm neutral about this. I 
feel that it is the way a modern library should behave. However I'm not 
sure that the fact that PLplot does not currently work this way is 
actually causing a lot of problems for people.

-Hazen

Re: [Plplot-devel] floating point exception in example 29

[Alan W. I. <ir...@be...>]

On 2015-05-12 09:41-0400 Hazen Babcock wrote:

>>
>> On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
>>>
>>> Hi Hazen:
>>>
>>> I am glad to hear you have created a topic branch that catches
>>> floating point exceptions.  However, I am not keen on pulling a PLplot
>>> topic branch from github for the reasons discussed in
>>> README.developers.  So could you either share your topic branch using
>>> "git format-patch" or else just push it to our official repo yourself?
>>> The former is preferred if the work is incomplete (i.e., does not
>>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
>>> macro is #defined). Furthermore, if the work is incomplete, I can
>>> finish the cmake aspects of it as promised above and amend your commit
>>> accordingly.
>>>
>>> Once we have implemented an option to check for floating-point
>>> exceptions, then that means any of us should be able to confirm the
>>> ones you have found and find others in the future due to the continued
>>> evolution of our examples.  And, of course, this option should allow
>>> us to fix those floating-point exceptions as time permits.
>>
>> Hi Alan,
>>
>> Sorry, that branch was not meant for incorporation into PLplot which is
>> why I did not follow accepted protocols. I thought it might make it
>> easier for others to see the floating point exception problem for these
>> 3 examples.
>>
>> I think we can enable floating point exception trapping more easily
>> using the -ffpe-trap option provided by gfortran. This won't require us
>> to mark up all of our C examples, though we might instead need to check
>> that the fortran compiler is gfortran?
>>
>> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>>
>> -ffpe-trap=invalid,zero,overflow,underflow
>>
>> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked"
>> for me in that it core dumps on the fortran equivalents of the C
>> examples I mentioned above. I've attached my CMakeCache.txt file.
>>
>> -Hazen
>
> Hm.. example 21 also generates an FPE, but at least in this case it
> looks like it is coming from the qhull library. And example 29 also
> generates an FPE, but only the Fortran version not the C version. So,
> maybe it would be better in the end to add this check to all of the C
> examples as well?

I sympathize with your desire not to mark up all the examples.  Which
lead to the thought that if gfortran has an option to report the above
exceptions without additional code markup, then gcc might have such
options as well.

A google search on the terms <gcc floating point exception traps>
found somehow else had asked that exact question at
<http://stackoverflow.com/questions/18644168/catch-floating-point-exceptions-using-a-compiler-option-with-c>

I don't understand the answers myself, but perhaps they might be useful
to you.

If it turns out the answer is currently "no" (i.e., you must mark up
the examples in order to detect floating-point exceptions with gcc),
then I think we could probably just stick with gfortran and
-ffpe-trap=invalid,zero,overflow,underflow.

Of course, the fortran examples go through a lot of additional code
before finally calling our core C library so this method should detect
floating-point exceptions in the fortran example implementation, the
fortran wrapper library code, AND, our core C library.  So we do want
to solve all of those.  Furthermore, once we have done so then I
believe the only C floating-point exception left that would go
undetected would be in the actual C example implementation, i.e., if
we divided by 0. right in one of the examples.  But we guard against
such issues in other ways (with the comparisons of PostScript and SVG
results) so I don't think we need to be concerned about such an issue.

If you agree with my above reasoning that gfortran with
-ffpe-trap=invalid,zero,overflow,underflow is what we want to do going
forward to detect floating point exceptions, then I hope you have the
time to fix all the causes of those exceptions in this release cycle.

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
__________________________

Re: [Plplot-devel] floating point exception in example 29

[Hazen B. <hba...@ma...>]

>
> On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
>>
>> Hi Hazen:
>>
>> I am glad to hear you have created a topic branch that catches
>> floating point exceptions.  However, I am not keen on pulling a PLplot
>> topic branch from github for the reasons discussed in
>> README.developers.  So could you either share your topic branch using
>> "git format-patch" or else just push it to our official repo yourself?
>> The former is preferred if the work is incomplete (i.e., does not
>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
>> macro is #defined). Furthermore, if the work is incomplete, I can
>> finish the cmake aspects of it as promised above and amend your commit
>> accordingly.
>>
>> Once we have implemented an option to check for floating-point
>> exceptions, then that means any of us should be able to confirm the
>> ones you have found and find others in the future due to the continued
>> evolution of our examples.  And, of course, this option should allow
>> us to fix those floating-point exceptions as time permits.
>
> Hi Alan,
>
> Sorry, that branch was not meant for incorporation into PLplot which is
> why I did not follow accepted protocols. I thought it might make it
> easier for others to see the floating point exception problem for these
> 3 examples.
>
> I think we can enable floating point exception trapping more easily
> using the -ffpe-trap option provided by gfortran. This won't require us
> to mark up all of our C examples, though we might instead need to check
> that the fortran compiler is gfortran?
>
> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>
> -ffpe-trap=invalid,zero,overflow,underflow
>
> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked"
> for me in that it core dumps on the fortran equivalents of the C
> examples I mentioned above. I've attached my CMakeCache.txt file.
>
> -Hazen

Hm.. example 21 also generates an FPE, but at least in this case it 
looks like it is coming from the qhull library. And example 29 also 
generates an FPE, but only the Fortran version not the C version. So, 
maybe it would be better in the end to add this check to all of the C 
examples as well?

-Hazen

Re: [Plplot-devel] floating point exception in example 29

[Hazen B. <hba...@ma...>]

On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
> On 2015-05-11 16:23-0400 Hazen Babcock wrote:
>>
>> Much time passes during which I never implement this branch as
>> promised, and it looks like some more floating point exceptions have
>> crept in. More specifically I'm seeing floating point exceptions in
>> x25, x30 and x33. The problem seems to be with plgradient() when it
>> uses a software fallback gradient (I was testing with the xwin driver).
>>
>> You can pull a branch with floating point exception trapping enabled
>> for these examples here:
>> https://github.com/HazenBabcock/PLplot/tree/fpe_x25_x30_x33
>>
>> The problem is occurring in notcrossed() in plfill.c at line 2040 when
>> converting from a PLFLT to a PLINT. It looks like fxintersect and
>> fyintersect can take on values that are too large to be converted to
>> integers. Checking for this fixes the problem, but maybe this is
>> indicating some problem upstream?
>
> Hi Hazen:
>
> I am glad to hear you have created a topic branch that catches
> floating point exceptions.  However, I am not keen on pulling a PLplot
> topic branch from github for the reasons discussed in
> README.developers.  So could you either share your topic branch using
> "git format-patch" or else just push it to our official repo yourself?
> The former is preferred if the work is incomplete (i.e., does not
> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
> macro is #defined). Furthermore, if the work is incomplete, I can
> finish the cmake aspects of it as promised above and amend your commit
> accordingly.
>
> Once we have implemented an option to check for floating-point
> exceptions, then that means any of us should be able to confirm the
> ones you have found and find others in the future due to the continued
> evolution of our examples.  And, of course, this option should allow
> us to fix those floating-point exceptions as time permits.

Hi Alan,

Sorry, that branch was not meant for incorporation into PLplot which is 
why I did not follow accepted protocols. I thought it might make it 
easier for others to see the floating point exception problem for these 
3 examples.

I think we can enable floating point exception trapping more easily 
using the -ffpe-trap option provided by gfortran. This won't require us 
to mark up all of our C examples, though we might instead need to check 
that the fortran compiler is gfortran?

https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html

-ffpe-trap=invalid,zero,overflow,underflow

Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked" 
for me in that it core dumps on the fortran equivalents of the C 
examples I mentioned above. I've attached my CMakeCache.txt file.

-Hazen

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

[Arjen M. <Arj...@de...>]

Hi Alan,



I used commit c67fd667347b09bf5d3be6c0bc73de3762e59ab1 and still see that warning. I have attached the compressed tar-ball for your convenience. (As the comprehensive tests fail with the traditional install tree, I have turned that off.)



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Tuesday, May 12, 2015 10:07 AM
To: Alan W. Irwin; PLplot development list
Subject: Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone


Hi Alan,



Okay, I will try that.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 12, 2015 1:26 AM
> To: Arjen Markus; PLplot development list
> Subject: Spurious warnings on Cygwin should now be gone
>
> Hi Arjen:
>
> The spurious warnings the subject line refers to are the messages starting with
>
> "CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15
> (message):
>    CMake no longer defines WIN32 on Cygwin!
> ..."
>
> that were showing up in the cmake.out files you were reporting for the Cygwin
> platform.
>
> I asked advice on the cmake list about how to get rid of those, and the response was
> to make sure cmake_minimum_required was always called before the project
> command.  (That change is highly recommended for other reasons as well.) I have
> now (commit id 80bacae) finished that suggested change for the PLplot build system,
> and I would appreciate you testing that change (by running a comprehensive test on
> the Cygwin
> platform) when you have a chance.
>
> 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
> __________________________
>
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Please check whether you can build on Mac OS X (was "Can't build on OS X Lion")

[Alan W. I. <ir...@be...>]

On 2012-08-20 20:10-0700 Jerry wrote:

>
> On Aug 20, 2012, at 2:07 PM, Andrew Ross wrote:
>
>> Jerry,
>>
>> Thanks. So my method did what it was meant to, but unforunately it looks
>> like we need to actually link in QtGui and QtSvg as well, so we might
>> as well just use QT_LIBRARIES without trying to parse it.
>>
>> Note that QtCore has to be explicitly linked in since qt.cpp references
>> QApplication.
>>
>> Classes from QtGui and QtSvg are not explictly mentioned in qt.cpp, but
>> derived classes (QtPLWidget etc from plplotqtd) are mentioned. On Linux
>> at least "ldd -u qt.so" shows these libraries as unused dependencies, but
>> "nm --demangle --undefined-only qt.so" contains references to functions
>> in these libraries. I don't quite understand why, but I think to be safe
>> we need to link with them, even if it causes warnings about linking
>> with unused dependencies.
>>
>> Andrew
>
> Great! 12218 builds Qt with NON_TRANSITIVE=ON.

To Andrew, Jim, and Jerry:

I am resurrecting this two-year-old thread because as of commit id
c67fd66 I have changed from deprecated to recommended CMake methods of
implementing NON_TRANSITIVE=ON, and while making the change, I noticed
Andrew's commit to always link ${QT_LIBRARIES} transitively to solve a
problem Jerry was having almost two years ago with building on Lion.

With the new method, I still link ${QT_LIBRARIES} transitively
(see notes in bindings/qt_gui/CMakeLists.txt) so I predict
all should be well when Jim or Jerry builds PLplot with qt on
whatever versions of Mac OS X they have installed.

@Jim and Jerry:
Could you please check that prediction when you get a chance?

@Andrew:

As we both already know "ldd -u" produces lots of false positives
about overlinking, but a google search shows that is not the correct way to use
that option, and you must always use the -r flag at the same time to get
reliable results.

So with the new linking implementation, here is the ldd -u -r
results for qt_example.

software@raven> ldd -u -r examples/c++/qt_example 
Unused direct dependencies:

         /usr/lib/x86_64-linux-gnu/libQtSvg.so.4

I believe "ldd -u -r" is working correctly here, i.e., that is a real
overlinking issue.  libQtSvg is only used to support the svgqt
device so it makes sense that it should not be needed by qt_example.
But I may be wrong here since you concluded above (two years ago)
that libQtSvg was needed.

Note, that although I felt you would be interested in this result, I
also don't think we should make any extraordinary attempts to drop
libQtSvg from this link step (even if you decide that is allowed)
since overlinking is not that harmful, and the above is a Qt4 result
(whose CMake support is very different from the CMake support for Qt5)
which will no longer be relevant once we fully switch to Qt5 (probably
still at least a year in the future depending on how soon the Qt5
alignment bugs are fixed).

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
__________________________

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

[Arjen M. <Arj...@de...>]

Hi Alan,



Okay, I will try that.



Regards,



Arjen




> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 12, 2015 1:26 AM
> To: Arjen Markus; PLplot development list
> Subject: Spurious warnings on Cygwin should now be gone
>
> Hi Arjen:
>
> The spurious warnings the subject line refers to are the messages starting with
>
> "CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15
> (message):
>    CMake no longer defines WIN32 on Cygwin!
> ..."
>
> that were showing up in the cmake.out files you were reporting for the Cygwin
> platform.
>
> I asked advice on the cmake list about how to get rid of those, and the response was
> to make sure cmake_minimum_required was always called before the project
> command.  (That change is highly recommended for other reasons as well.) I have
> now (commit id 80bacae) finished that suggested change for the PLplot build system,
> and I would appreciate you testing that change (by running a comprehensive test on
> the Cygwin
> platform) when you have a chance.
>
> 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
> __________________________
>

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Spurious warnings on Cygwin should now be gone

[Alan W. I. <ir...@be...>]

Hi Arjen:

The spurious warnings the subject line refers to are the messages
starting with

"CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):
   CMake no longer defines WIN32 on Cygwin!
..."

that were showing up in the cmake.out files you were reporting for the
Cygwin platform.

I asked advice on the cmake list about how to get rid of those, and
the response was to make sure cmake_minimum_required was always called
before the project command.  (That change is highly recommended for
other reasons as well.) I have now (commit id 80bacae) finished that
suggested change for the PLplot build system, and I would appreciate
you testing that change (by running a comprehensive test on the Cygwin
platform) when you have a chance.

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
__________________________

Re: [Plplot-devel] floating point exception in example 29

[Alan W. I. <ir...@be...>]

On 2015-05-11 16:23-0400 Hazen Babcock wrote:

> On 04/15/2014 07:44 AM, Hazen Babcock wrote:
>> On 4/7/2014 11:08 PM, Alan W. Irwin wrote:
>>> I have just had a further idea. For comprehensive testing situations
>>> it might be good to have the option to call feenableexcept (the C
>>> library function that you used to help debug x29c.c that should be
>>> available for c99 according to its Linux man page) from within the
>>> PLplot library (say as the result of plinit).  If you agree (a) that
>>> idea would work and (b) it would be useful, would you be willing to
>>> implement it in C for the case when the PLPLOT_ENABLE_FLOAT_EXCEPT C
>>> macro is #defined?  If so, I would be willing to do the rest on the
>>> CMake side (create a CMake option for this and propagate it to the
>>> corresponding C macro for the compilation of the source file where you
>>> have implemented the feenableexcept call).
>> 
>> I have tested the idea and it works. I'm not sure about the utility
>> though. Based on my tests it already caught the only error in the
>> examples that it is going to catch. After the git transition I can
>> create a branch that will catch floating point exceptions and you can
>> merge it (or not) into the master branch based on your feeling about
>> it's utility.
>
> Much time passes during which I never implement this branch as promised, and 
> it looks like some more floating point exceptions have crept in. More 
> specifically I'm seeing floating point exceptions in x25, x30 and x33. The 
> problem seems to be with plgradient() when it uses a software fallback 
> gradient (I was testing with the xwin driver).
>
> You can pull a branch with floating point exception trapping enabled for 
> these examples here:
> https://github.com/HazenBabcock/PLplot/tree/fpe_x25_x30_x33
>
> The problem is occurring in notcrossed() in plfill.c at line 2040 when 
> converting from a PLFLT to a PLINT. It looks like fxintersect and fyintersect 
> can take on values that are too large to be converted to integers. Checking 
> for this fixes the problem, but maybe this is indicating some problem 
> upstream?

Hi Hazen:

I am glad to hear you have created a topic branch that catches
floating point exceptions.  However, I am not keen on pulling a PLplot
topic branch from github for the reasons discussed in
README.developers.  So could you either share your topic branch using
"git format-patch" or else just push it to our official repo yourself?
The former is preferred if the work is incomplete (i.e., does not
include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
macro is #defined). Furthermore, if the work is incomplete, I can
finish the cmake aspects of it as promised above and amend your commit
accordingly.

Once we have implemented an option to check for floating-point
exceptions, then that means any of us should be able to confirm the
ones you have found and find others in the future due to the continued
evolution of our examples.  And, of course, this option should allow
us to fix those floating-point exceptions as time permits.

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
__________________________

Re: [Plplot-devel] floating point exception in example 29

[Hazen B. <hba...@ma...>]

On 04/15/2014 07:44 AM, Hazen Babcock wrote:
> On 4/7/2014 11:08 PM, Alan W. Irwin wrote:
>> I have just had a further idea. For comprehensive testing situations
>> it might be good to have the option to call feenableexcept (the C
>> library function that you used to help debug x29c.c that should be
>> available for c99 according to its Linux man page) from within the
>> PLplot library (say as the result of plinit).  If you agree (a) that
>> idea would work and (b) it would be useful, would you be willing to
>> implement it in C for the case when the PLPLOT_ENABLE_FLOAT_EXCEPT C
>> macro is #defined?  If so, I would be willing to do the rest on the
>> CMake side (create a CMake option for this and propagate it to the
>> corresponding C macro for the compilation of the source file where you
>> have implemented the feenableexcept call).
>
> I have tested the idea and it works. I'm not sure about the utility
> though. Based on my tests it already caught the only error in the
> examples that it is going to catch. After the git transition I can
> create a branch that will catch floating point exceptions and you can
> merge it (or not) into the master branch based on your feeling about
> it's utility.

Much time passes during which I never implement this branch as promised, 
and it looks like some more floating point exceptions have crept in. 
More specifically I'm seeing floating point exceptions in x25, x30 and 
x33. The problem seems to be with plgradient() when it uses a software 
fallback gradient (I was testing with the xwin driver).

You can pull a branch with floating point exception trapping enabled for 
these examples here:
https://github.com/HazenBabcock/PLplot/tree/fpe_x25_x30_x33

The problem is occurring in notcrossed() in plfill.c at line 2040 when 
converting from a PLFLT to a PLINT. It looks like fxintersect and 
fyintersect can take on values that are too large to be converted to 
integers. Checking for this fixes the problem, but maybe this is 
indicating some problem upstream?

-Hazen

Re: [Plplot-devel] Substantial change in scripts/comprehensive_test.sh

[Alan W. I. <ir...@be...>]

On 2015-05-11 06:46-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Thanks - this [collection of results into a tarball] will provide a uniform report. I will run it today.

Hi Arjen:

When you do run scripts/comprehensive_test.sh make sure to use
the latest master tip version.  I have just now (commit id 0f1adc2)
added the CMake cache files to what is collected into the tarball.

Here is the latest table of contents from that tarball for a
particular (interactive tests dropped) comprehensive test I just did:

-rw-r--r-- software/software 7556 2015-05-11 11:31 comprehensive_test.sh.out
-rw-r--r-- software/software 1623 2015-05-11 11:25 comprehensive_test_env.out
drwxr-xr-x software/software    0 2015-05-11 11:27 shared/output_tree/
-rw-r--r-- software/software 3463 2015-05-11 11:26 shared/output_tree/installed_cmake.out
-rw-r--r-- software/software 188116 2015-05-11 11:27 shared/output_tree/installed_make_noninteractive.out
-rw-r--r-- software/software 105220 2015-05-11 11:26 shared/output_tree/make_noninteractive.out
-rw-r--r-- software/software    943 2015-05-11 11:27 shared/output_tree/traditional_clean.out
-rw-r--r-- software/software      0 2015-05-11 11:26 shared/output_tree/clean.out
-rw-r--r-- software/software  14020 2015-05-11 11:25 shared/output_tree/cmake.out
-rw-r--r-- software/software   4335 2015-05-11 11:26 shared/output_tree/ctest.out
-rw-r--r-- software/software      0 2015-05-11 11:27 shared/output_tree/installed_clean.out
-rw-r--r-- software/software 377492 2015-05-11 11:25 shared/output_tree/make.out
-rw-r--r-- software/software 162403 2015-05-11 11:26 shared/output_tree/make_install.out
-rw-r--r-- software/software     91 2015-05-11 11:26 shared/output_tree/clean_ctest_plot_files.out
-rw-r--r-- software/software  20417 2015-05-11 11:27 shared/output_tree/traditional_make_noninteractive.out
-rw-r--r-- software/software  50139 2015-05-11 11:25 shared/build_tree/CMakeCache.txt
-rw-r--r-- software/software  11863 2015-05-11 11:26 shared/install_build_tree/CMakeCache.txt
drwxr-xr-x software/software      0 2015-05-11 11:29 nondynamic/output_tree/
-rw-r--r-- software/software   3475 2015-05-11 11:28 nondynamic/output_tree/installed_cmake.out
-rw-r--r-- software/software 193628 2015-05-11 11:29 nondynamic/output_tree/installed_make_noninteractive.out
-rw-r--r-- software/software 103182 2015-05-11 11:28 nondynamic/output_tree/make_noninteractive.out
-rw-r--r-- software/software    959 2015-05-11 11:29 nondynamic/output_tree/traditional_clean.out
-rw-r--r-- software/software      0 2015-05-11 11:28 nondynamic/output_tree/clean.out
-rw-r--r-- software/software  14298 2015-05-11 11:27 nondynamic/output_tree/cmake.out
-rw-r--r-- software/software   4383 2015-05-11 11:28 nondynamic/output_tree/ctest.out
-rw-r--r-- software/software      0 2015-05-11 11:29 nondynamic/output_tree/installed_clean.out
-rw-r--r-- software/software 362574 2015-05-11 11:27 nondynamic/output_tree/make.out
-rw-r--r-- software/software 146474 2015-05-11 11:28 nondynamic/output_tree/make_install.out
-rw-r--r-- software/software     91 2015-05-11 11:28 nondynamic/output_tree/clean_ctest_plot_files.out
-rw-r--r-- software/software  32537 2015-05-11 11:29 nondynamic/output_tree/traditional_make_noninteractive.out
-rw-r--r-- software/software  49238 2015-05-11 11:27 nondynamic/build_tree/CMakeCache.txt
-rw-r--r-- software/software  11887 2015-05-11 11:28 nondynamic/install_build_tree/CMakeCache.txt
drwxr-xr-x software/software      0 2015-05-11 11:31 static/output_tree/
-rw-r--r-- software/software   3028 2015-05-11 11:30 static/output_tree/installed_cmake.out
-rw-r--r-- software/software 201637 2015-05-11 11:31 static/output_tree/installed_make_noninteractive.out
-rw-r--r-- software/software 100644 2015-05-11 11:30 static/output_tree/make_noninteractive.out
-rw-r--r-- software/software    943 2015-05-11 11:31 static/output_tree/traditional_clean.out
-rw-r--r-- software/software      0 2015-05-11 11:30 static/output_tree/clean.out
-rw-r--r-- software/software  13928 2015-05-11 11:29 static/output_tree/cmake.out
-rw-r--r-- software/software   4335 2015-05-11 11:30 static/output_tree/ctest.out
-rw-r--r-- software/software      0 2015-05-11 11:31 static/output_tree/installed_clean.out
-rw-r--r-- software/software 334158 2015-05-11 11:29 static/output_tree/make.out
-rw-r--r-- software/software 139723 2015-05-11 11:30 static/output_tree/make_install.out
-rw-r--r-- software/software     91 2015-05-11 11:30 static/output_tree/clean_ctest_plot_files.out
-rw-r--r-- software/software  31977 2015-05-11 11:31 static/output_tree/traditional_make_noninteractive.out
-rw-r--r-- software/software  49196 2015-05-11 11:29 static/build_tree/CMakeCache.txt
-rw-r--r-- software/software  11863 2015-05-11 11:30 static/install_build_tree/CMakeCache.txt
-rw-r--r-- software/software 738102 2015-05-11 11:31 comprehensive_test_listing.out

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
__________________________

Re: [Plplot-devel] Substantial change in scripts/comprehensive_test.sh

[Arjen M. <Arj...@de...>]

Hi Alan,



Thanks - this will provide a uniform report. I will run it today.



Regards,



Arjen






> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, May 09, 2015 8:57 AM
> To: Arjen Markus; Andrew Ross
> Cc: PLplot development list
> Subject: Substantial change in scripts/comprehensive_test.sh
>
> To Arjen and Andrew (and others here interested in doing comprehensive
> testing):
>
> Please note the script has now (commit id 61494c1) been substantially modified to
> collect all information desired for a comprenhensive test report so you no longer
> have to do this yourself.
>
> That collected information automatically appears as the file
> comprehensive_test.tar.gz in the prefix directory, and that tarball contains
>
> 1. Environment variable output
> 2. Script output
> 3. All */output_tree files
> 4. A complete listing of all files
>
> So from now on when reporting results of scripts/comprehensive_testing.sh, please
> just attach comprehensive_test.tar.gz to the post so I have the information required
> to figure out what is going on whether the script succeeded or failed on your platform.
>
> 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
> __________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] [Plplot-general] memqt alone

[Alan W. I. <ir...@be...>]

On 2015-05-09 08:43-0500 Aaron Hexamer wrote:

> Alan
>
> Thanks for the explanation.  I've attached a patch [to fix the
memqt-only case], but I must caveat that
> it's only been tested in the limited context of my application.  In
> particular I'm concerned that the code I stripped out of qt.cmake is there
> for some good reason, but I can't figure out what that is.

Hi Aaron:

As stated on plplot-general, I have moved this topic to the
plplot-devel mailing list in case there is any further posts in this
thread after this one.  I also encourage you to subscribe to
plplot-devel.

I implemented the logic in qt.cmake some time ago that your commit
removes, but I agree with you there is not much point to it so I think
your removal was correct. Furthermore, I removed one other nonsensical
piece of logic in that file and did a few other small changes in
addition to yours.

Thanks for formatting your patch with git format-patch.
I made that commit on a topic branch using "git am" and then amended that
commit further with git commit --amend before pushing it.

Those further (small) changes were in the following files:

#       modified:   cmake/modules/drivers-init.cmake
#       modified:   cmake/modules/qt.cmake
#       modified:   examples/c++/CMakeLists.txt

They identified memqt as a memory device (as opposed to an external
device which is good for human interpretation but makes no practical
difference to the build system) and consistently used PLD_extqt rather
than ENABLE_qt to identify when the pyqt4 bindings should be implemented
and the qt_example application built.

I found ways to test both extqt alone and memqt alone, and those
results were satisfactory.  See the commit message for commit id
7f9ba09 for more details of those tests.

Please try this commit and let me know whether it satisfies
your needs.

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
__________________________

[Plplot-devel] The PLplot build system now uses CMake policy CMP0026 NEW

[Alan W. I. <ir...@be...>]

This change (as of fc80e786) to our build system where we replace
deprecated build-target LOCATION properties with the corresponding
generator expressions is quite intrusive. I have comprehensively
tested this change on Linux, but it also needs comprehensive testing
on all other platforms and especially on Cygwin where the change
(actually a required workaround for a permissions bug associated with
the change for versions of CMake less than 3.2) requires a GNU
extension of the chmod command to work.

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
__________________________

[Plplot-devel] Bumped minimum version of CMake to 3.2.2 for all but Linux and Cygwin systems

[Alan W. I. <ir...@be...>]

I have (as of commit id 6c847e28) bumped the minimum version of CMake
to 3.2.2 on all platforms other than Linux and Cygwin.  The reason
for this is to avoid a file(GENERATE...) permissions bug in CMake-3 that occurs
for all versions less than 3.2 where a convenient workaround for the bug
can be done with a GNU extension of chmod that is only available
for Linux and Cygwin.

I plan for the next two years or so to keep the minimum version of
CMake for Linux and Cygwin at 3.0.2 which allows most Linux and Cygwin
users to use the system version of CMake on their platform.

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
__________________________

[Plplot-devel] Substantial change in scripts/comprehensive_test.sh

[Alan W. I. <ir...@be...>]

To Arjen and Andrew (and others here interested in doing comprehensive
testing):

Please note the script has now (commit id 61494c1) been substantially
modified to collect all information desired for a comprenhensive
test report so you no longer have to do this yourself.

That collected information automatically appears as the
file comprehensive_test.tar.gz in the prefix directory, and
that tarball contains

1. Environment variable output
2. Script output
3. All */output_tree files
4. A complete listing of all files

So from now on when reporting results of
scripts/comprehensive_testing.sh, please just attach
comprehensive_test.tar.gz to the post so I have the information
required to figure out what is going on whether the script succeeded
or failed on your platform.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



I completely forgot to send the results of that test. The fixes do work but there is a strange build error with the "installed" part of the test. See the attachment.



Regards,



Arjen


From: Arjen Markus
Sent: Tuesday, April 21, 2015 10:12 PM
To: 'Alan W. Irwin'
Cc: PLplot development list
Subject: RE: [Plplot-devel] Comprehensive testing: MinGW/MSYS


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Good detective work!  I agree you have completely pinned down the issue now, and
> I look forward to your commit with the fix for plInBuildTree.
>
I am confident that the fix works for all our Windows environments, as I use the WIN32_OR_CYGWIN variable to control the logic in plInBuildTree. When I tried it earlier with a more restricted fix (using the C macro WIN32), the whole comprehensive test ran fine. I do not have time right now to repeat this, but testing an example manually did what it was expected to do.

I will run the comprehensive test tomorrow.

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Problems using the plplot cmake config file

[Alan W. I. <ir...@be...>]

On 2015-04-24 11:52-0700 Alan W. Irwin wrote:

> I assume what you are trying to do is make a fully-loaded build of
> PLplot and then split up the results into a bunch of different binary
> packages, but if you look at export_plplot.cmake (which generated the
> above error message) you can see the problem; it loops over all PLplot
> targets that were exported in the fully-loaded build of PLplot and
> errors out on the targets which you have attempted to split into
> separate binary components.
>
> Since split binary targets have been around from the early days of
> rpm, I am pretty sure that CMake supports that idea when exporting
> targets, but I currently don't know how to take advantage of such
> CMake functionality if it exists.  So I will ask a question on the
> CMake list about this.

To Orion, Andrew, and all other binary packagers of PLplot:

I have explored the above issue on the cmake mailing list (with
subject line "What is the proper way to export targets that will be
split into separate binary packages?") and got what appear to be
definitive responses.

It turns out to deal with this issue some substantial but reasonably
straightforward changes have to be made in the way we export our
targets. Clearly, those changes should be done to bring the PLplot
cmake package up to modern standards. Furthermore, those changes imply
there will be a separate CMake package target file for each of our ~30
targets that are exported with one overall hand-written configuration
file (see src/plplotConfig.cmake which is largely just a placeholder
now) to organize those individual target files into the CMake package
for PLplot (most likely without any further organization into
individual CMake package components).  Furthermore, the CMake logic in
the updated src/plplotConfig.cmake file should be able to loop through
the individual target files that hapen to be installed. So once I get
the CMake package for PLplot modernized in this way, I am pretty sure
a binary packager's job would boil down to deciding which of the
target files should be collected into the individual binary packages,
and if a user decides not to install some of those binary packages,
the logic in the revised src/plplotConfig.cmake should just continue
to work.

In sum, it appears that it will be possible to combine split binary
packages and a modernized version of the CMake package for PLplot, but
there will be lots of implementation work for me to do in this release
cycle before we get there.

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
__________________________

Re: [Plplot-devel] Fedora plplot patches

[Orion P. <or...@co...>]

On 04/25/2015 11:05 AM, Alan W. Irwin wrote:
> While we are at it, are there any other general issues like this one
> (i.e., issues likely to affect all distros) addressed by the Fedora
> downstream patches which we should be aware of upstream?

There are two other issues currently addressed downstream, which I'm 
pretty sure I've raised here before.  The ocaml one relatively recently, 
not sure about the multiarch one.

Patch2:         plplot-multiarch.patch

This allows for the "core" plplot package to be "multiarch" - exactly 
the same content for 32-bit and 64-bit builds.  Otherwise the 
PKG_CONFIG_ENV and RPATH variables have /usr/lib or /usr/lib64 in them. 
  I know this patch isn't acceptable upstream as it is, but if you found 
a way to address it, that would be great.

# Don't use -custom with ocamlc
Patch7:         plplot-ocaml.patch

I've attached both.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Plplot-devel] Incorrect pkg-config link flags with plplot 5.11.0

[Alan W. I. <ir...@be...>]

On 2015-04-25 09:59-0600 Orion Poplawski wrote:

> On 04/24/2015 07:58 PM, Alan W. Irwin wrote:
>> On 2015-04-24 10:09-0600 Orion Poplawski wrote:
[...]
>>> Libs: -L${libdir} -lplplotd
>> 
>> I don't get that at all for 5.10.0.
>
> Ah, mea culpa, we had:
>
> # Fix pkgconfig libs
> # https://bugzilla.redhat.com/show_bug.cgi?id=998988
> Patch4:         plplot-pkgconfig.patch
>
> diff -up plplot-5.9.9-svn12479/src/CMakeLists.txt.pkgconfig 
> plplot-5.9.9-svn12479/src/CMakeLists.txt
> --- plplot-5.9.9-svn12479/src/CMakeLists.txt.pkgconfig  2013-07-09 
> 13:27:35.000000000 -0600
> +++ plplot-5.9.9-svn12479/src/CMakeLists.txt    2013-08-23 10:17:31.522913437 
> -0600
> @@ -472,7 +472,9 @@ if(PKG_CONFIG_EXECUTABLE)
>   string(REGEX REPLACE "^.*:(.*):.*:.*$" "\\1" PC_SHORT_NAME ${PC_DATA})
>   string(REGEX REPLACE "^.*:.*:(.*):.*$" "\\1" PC_LONG_NAME ${PC_DATA})
>   string(REGEX REPLACE "^.*:.*:.*:(.*)$" "\\1" PC_LIBRARY_NAME ${PC_DATA})
> -  set(PC_LINK_FLAGS "${lib${PC_LIBRARY_NAME}_LINK_FLAGS}")
> +  if(NOT BUILD_SHARED_LIBS)
> +    set(PC_LINK_FLAGS "${lib${PC_LIBRARY_NAME}_LINK_FLAGS}")
> +  endif(NOT BUILD_SHARED_LIBS)
>   set(PC_LINK_FLAGS "-l${PC_LIBRARY_NAME} ${PC_LINK_FLAGS}")
>   set(PC_COMPILE_FLAGS "${lib${PC_LIBRARY_NAME}_COMPILE_FLAGS}")
>   set(PC_CONFIGURED_FILE

Thanks for figuring that out.

Of course, once I get the general shared versus static linking issue
for PLplot pkg-config results fixed upstream, that downstream patch
will no longer be necessary.

While we are at it, are there any other general issues like this one
(i.e., issues likely to affect all distros) addressed by the Fedora
downstream patches which we should be aware of upstream?

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
__________________________

Re: [Plplot-devel] fortran example compile error

[Orion P. <or...@co...>]

On 04/24/2015 08:08 PM, Alan W. Irwin wrote:
> On 2015-04-24 16:51-0600 Orion Poplawski wrote:
>
>> # make
>> /usr/bin/gfortran  x00f.f90 -o x00f  -I/usr/include/plplot
>> -I/usr/lib64/gfortran/modules -I/usr/include/plplot -lplplotf95
>> -lplf95demolib
>> /usr/bin/ld: /tmp/ccNUjhko.o: undefined reference to symbol 'plinit_'
>> /usr/lib64/libplplotf95c.so.12: error adding symbols: DSO missing from
>> command
>> line
>> collect2: error: ld returned 1 exit status
>> # grep -Fi plinit x00f.f90
>>    call plinit
>>
>> /usr/lib64/libplplotf95c.so
>> 0000000000009350 T plinit_
>>
>> So we need to link with -lplplotf95c
>
> Please clarify which of three build systems (build tree configured
> with cmake, installed examples tree configured with cmake, or
> traditional installed examples tree configured with pkg-config) generate
> the above error on Fedora.
>

Installed examples tree using the installed Makefile.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Plplot-devel] fortran example compile error

[Alan W. I. <ir...@be...>]

On 2015-04-24 16:51-0600 Orion Poplawski wrote:

> # make
> /usr/bin/gfortran  x00f.f90 -o x00f  -I/usr/include/plplot
> -I/usr/lib64/gfortran/modules -I/usr/include/plplot -lplplotf95  -lplf95demolib
> /usr/bin/ld: /tmp/ccNUjhko.o: undefined reference to symbol 'plinit_'
> /usr/lib64/libplplotf95c.so.12: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> # grep -Fi plinit x00f.f90
>    call plinit
>
> /usr/lib64/libplplotf95c.so
> 0000000000009350 T plinit_
>
> So we need to link with -lplplotf95c

Please clarify which of three build systems (build tree configured
with cmake, installed examples tree configured with cmake, or
traditional installed examples tree configured with pkg-config) generate
the above error on Fedora.

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
__________________________

Re: [Plplot-devel] Incorrect pkg-config link flags with plplot 5.11.0

[Alan W. I. <ir...@be...>]

On 2015-04-24 10:09-0600 Orion Poplawski wrote:

>> I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and
>> they are the same other than dropping the "d" suffix. So the change in
>> pkg-config result must not be due to something being done differently
>> by PLplot. Instead, my guess is Fedora is likely doing something
>> different now with pkg-config.  For example, perhaps before they
>> massaged pkg-config results but now they no longer do so more pkg-config
>> transitive linking issues are revealed?
>
> This is an incorrect assumption.  While the *.pc.in files are the same, the
> way that you generate PC_LINK_FLAGS has obviously changed

Likely not in the 5.11.0 release cycle.  The above (identical) results
I refer to are for what is configured in 5.10.0 and what is configured
in 5.11.0 for the Libs: line in the *.pc files.

> producing the final difference in the generated *.pc file.  My F21 plplotd.pc
> file has:
>
> Libs: -L${libdir} -lplplotd

I don't get that at all for 5.10.0.  So it looks like you have found a
PLplot regression, but to confirm that here I need to know the exact
upstream version of PLplot where I should get the simple result for
the configured Libs: line.  Or did you get that simple result because
of some downstream patch you applied?

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
__________________________