plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] wxwidgets error when building plplot 5.11.0 on FreeBSD

[Phil R. <p.d...@gm...>]

Hi Alan and Ben
Yes, with the new system in place a new wxPNG driver would be as
simple as passing in a memoryDC then a function call to write it to
file as any number of raster formats. It was on my list before the
last release, but I never quite found the time. It is still on the
list though for next release.

Phil

On 20 April 2015 at 00:38, Ben Woods <woo...@gm...> wrote:
> Thanks for the feedback Alan.
>
> I have removed the -DPLD_wxpng:BOOL=ON option and it is all working well
> now. Thanks!
>
> Regards,
> Ben
>
> On Fri, 17 Apr 2015 at 9:23 am Alan W. Irwin <ir...@be...>
> wrote:
>>
>> On 2015-04-16 22:48-0000 Ben Woods wrote:
>>
>> > Hey everyone,
>> >
>> > I'm trying to build plplot 5.11.0 on FreeBSD with wxwidgets support. I
>> > have wx28-gtk2-2.8.12 and agg-2.5_11 installed, and am compiling with
>> > the following options:
>> > -DPLD_wxpng:BOOL=ON
>> >
>> > -DwxWidgets_CONFIG_EXECUTABLE:FILEPATH="/usr/local/bin/wxgtk2-2.8-config"
>>
>>
>> > -- WARNING: You have enabled the PLD_wxpng device which is disabled by
>> > default either because it is deprecated or because there are know
>> > issues with it. Please check the documentation / release notes for
>> > details.
>>
>> Hi Ben:
>>
>> I have reviewed our old mailing list archive and
>> PLD_wxpng has been disabled by default since its implementation many
>> years ago because it had all sorts of run-time problems (segfaults, etc.),
>> and nobody has fixed it since.
>>
>> Just out of curiosity I tried to use
>>
>> -DPLD_wxpng:BOOL=ON
>>
>> as you did above,
>>
>> and I got the following build error (which apparently is not the same as
>> your
>> build error):
>>
>> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In function
>> ‘void plD_init_wxpng(PLStream*)’:
>> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:5: error:
>> ‘wxPLDevBase’ was not declared in this scope
>> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:18: error:
>> ‘dev’ was not declared in this scope
>> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:232:28: error:
>> ‘common_init’ was not declared in this scope
>> make[3]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.o] Error 1
>> make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2
>> make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/rule] Error 2
>> make: *** [wxwidgets] Error 2
>>
>> So it appears wxpng has fallen into even a greater state of
>> disrepair (it now doesn't even build) for the new wxwidgets implementation
>> used for 5.11.0.  It might build (but would probably still have the
>> same run-time errors as previously) if you used the -DOLD_WXWIDGETS=ON
>> option we have implemented for 5.11.0 to give access to the old
>> wxwidgets implementation.
>>
>> But I think what you really should do is pay attention to the above
>> warning message and do not use the -DPLD_wxpng:BOOL=ON option for
>> 5.11.0 at all.
>>
>> @Phil:
>>
>> I think Werner's historical idea with wxpng was as a proof-of-concept
>> that wxwidgets could be the basis of a whole bunch of additional file
>> device drivers.  He obviously never got that idea to work properly,
>> but it might be a lot easier now with modern wxwidgets and your
>> simplification/rationalization of our own wxwidgets-related code.
>>
>> Anyhow, my advice is to consider this possibility.  If you think wxpng
>> (and other possible file devices) are a good idea and straightforward
>> to implement properly with you new wxwidgets approach, then please put
>> getting wxpng to build and actually execute properly without segfaults
>> on your wxwidgets ToDo list.  Otherwise, though, you should remove the
>> wxpng code from your new wxwidgets source files so nobody runs into
>> the type of build errors I did above for new wxwidgets.
>>
>> 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-18 00:57-0700 Alan W. Irwin wrote:

> On 2015-05-18 06:56-0000 Arjen Markus wrote:
>
>> Hi Alan,
>>
>>
>>
>> With the latest version the [Cygwin] warnings are indeed gone:
>
> Hi Arjen:
>
> It was good to hear that issue (and other more subtle/dangerous
> issues for which that spurious warning message was just one symptom)
> has finally been put to rest by the latest startup procedure.

Hi Arjen:

I spoke too soon; your latest comprehensive test report tarball for
Cygwin still shows one final "CMake no longer defines WIN32 on
Cygwin!" warning being generated by the Ada language support in the
cmake.out files.  This is yet another instance of the rule that
computers were put in our lives for the sole purpose of keeping us
humble.  :-)

It turned out in this case the warning was actually correct and not
spurious; project was being called in the Ada language support files
without any preceding call to cmake_minimum_required.  But I have now
fixed that issue (c4ba870) so all these warnings should finally be
completely gone on Cygwin (he says for ~3rd! time).

I don't think there is any need to do a special comprehensive test of
this fix on Cygwin, but instead I will just look carefully for any
further such warnings in cmake.out the next time you comprehensively
test on Cygwin for any other reason.

My (humble!) best wishes.

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] A possible design of our new Fortran binding

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

On 2015-05-21 07:53-0000 Arjen Markus wrote:

> Hi Alan, James,
>
>
>
> In the attachment you will find a demonstration of the sort of Fortran bindings I have in mind. The essence is:
>
> -        Use iso_c_binding to call the C functions directly (no intervening C wrapper if that can be avoided)
>
> -        Use the renaming feature of the use statement to switch between single and double precision without code duplication. The result is that the bindings provide two versions, one for single-precision arguments and one for double-precision arguments, which are selected automatically by the compiler. (Mixtures of precisions within a single call are not supported - that would lead to a very akward combinatorics and I doubt this at all a practical use case.)
>
> -        Hide those things like parameters that are not intended for the public interface. I will probably go and use "private" as the default and make the individual items public instead of what I have now (default "public" and hide the things that are not needed)
>
> The source code currently is tuned to example x00f, slightly modified wrt the trunk. You can change the worknig precision parameter "wp" to select the other precision.
>
> Notes:
>
> -        newbinding.f90 is the topmost source file. All other files are included into it.
>
> -        To link the example you need the PLplot C library. See the shell script "mk", which was set up for Cygwin
>
> -        With slight modifications this should work on Linux too (there you can use the libplplot.so shared object directly).
>

Hi Arjen:

A Linux adaptation of those build instructions got that build to work
for me (with some spurious warnings because of my old gfortran 4.7.2
version as we have discussed before.)

The end result was

irwin@raven> ./x00f

worked and prompted me for device and device file name, and the
resulting PostScript plot looked good.

So that is an excellent start, and I especially like the absence of
any extra C layer at this stage (although we will ultimately need an
extremely limited C layer for some of the more complex API argument
processing); the freedom to choose any real type in the examples (so
long as that real type is chosen consistently for a single call to a
PLplot function); and the form of how you have implemented the
interface which avoids duplicate code to handle the two different
PLFLT cases.

However, there are three things we should fix before expanding
this further.

1. Fix plsparseopts 
> -        I have not tested this with command-line arguments yet - that is the trickier part of the code.

In fact, it turns out command-line options do not work correctly, e.g.,

irwin@raven> ./x00f -dev psttfc -o test.psc

Bad command line option "test.psc"
[....]

2. Fix naming scheme for kind values so the examples (and more
importantly user's programmes which are depending on plflt) can remain unchanged
for backwards compatibility.  I have developed some detailed ideas in
the way I want to do this, but instead of describing those in English
I would like to present a commit instead that you could evaluate in
detail for yourself.

3. Integrate these changes into our current build and test scheme.
Again, I would be happy to take responsibility for this.

In sum, I suggest we continue from this good start on the new Fortran
binding topic with you taking responsibility for topic 1 and me taking
responsibility for topics 2 and 3 above.

Of course, if I am going to contribute to this development I do need
git access to your private topic branch work using the usual "git
format-patch" and "git am" method that is described in
README.developers. So for now I suggest your first priority would be
to present exactly what you have given us here as a tarball in "git
format-patch" form instead with no further changes (except possibly
not including the x00f.f90 change since I would just revert that, see
above).  And that solid git start with just your present work and no
further except possibly excluding the x00f.f90 change would allow us
to develop this private topic from there. Of course, I am aware you
have had some problems with using "git format-patch" in the past, but
if those continue let me know here or off list, and I think I should
be able to give you an exact cookbook of what to do to get started.

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] Results of the comprehensive test on Cygwin

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

On 2015-05-21 08:07-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>
>>
>> The first error message for the case of the traditional build of the f95 examples when
>> PLplot was statically built was as follows:
>>
>> /cygdrive/d/plplot-
>> svn/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(qt.cpp.o):qt.cpp
>> :(.text+0x5cc0):
>> undefined reference to std::ios_base::Init::Init()'
>>
>> std refers to symbols in the special library that the C++ compiler normally adds to the
>> linking information (in this case the libstdc++ library that is associated with g++, but
>> the name/location/version of that library might depend on which C++ compiler the
>> user decides to use).  Of course, in this case we must link the Fortran examples with
>> a Fortran compiler for the traditional build system for the installed example.
>> Therefore, there is a linking error here because libstdc++ is obviously not
>> automatically linked in by gfortran.  There are also similar potential problems for
>> other non-C or C++ examples that are compiled.
>>

> Ah, that is indeed a familiar problem. If I understand it correctly,
then C++ code requires a linker with libraries suitable for C++. Of
course Fortran and other languages require their own libraries and it
is usually the compiler (or the driver program) that adds the
appropriate ones to the link step. One can get around this problem by
explicitly supplying these libraries, but that is very much
compiler-specific and even configuration-specific (for instance: under
Windows the libraries for a debuggable program tend to be different
than those for a release program).

Exactly.  CMake handles finding the missing special libraries for each
different compiler with a lot of machinery under the hood that has
been developed over the years, but there is no way that our
traditional pkg-config + Makefile build system for the installed
examples can or should be that sophisticated.

> I will give this new set-up a try. Since it is the computer which does most work, it should not be that time-consuming for me.

I saw your later post that reported complete success.  That was good
to see (!), and I will take a detailed look at that report tarball and
also post that good test result on our Wiki after I have had some
sleep.

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] Results of the comprehensive test on Cygwin

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

Hi Alan,



The comprehensive test has finished on Cygwin without any complaints. I have not checked the report extensively but it looks as if all went well - no deviations reported. The details are in the attachment.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, May 21, 2015 8:03 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: Results of the comprehensive test on Cygwin
>
> On 2015-05-18 08:17-0000 Arjen Markus wrote:
>
> > Please find the results of the comprehensive test on Cygwin using
> the latest version. It fails in the static build, using the installed examples, but the
> other configurations seem fine. So we are making progress. What is going wrong
> with the installed examples is, however, a mystery to me.
>
> The first error message for the case of the traditional build of the f95 examples when
> PLplot was statically built was as follows:
>
> /cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(qt.cpp.o):qt.cpp
> :(.text+0x5cc0):
> undefined reference to std::ios_base::Init::Init()'
>
> std refers to symbols in the special library that the C++ compiler normally adds to the
> linking information (in this case the libstdc++ library that is associated with g++, but
> the name/location/version of that library might depend on which C++ compiler the
> user decides to use).  Of course, in this case we must link the Fortran examples with
> a Fortran compiler for the traditional build system for the installed example.
> Therefore, there is a linking error here because libstdc++ is obviously not
> automatically linked in by gfortran.  There are also similar potential problems for
> other non-C or C++ examples that are compiled.
>
> It took some doing (because on Debian wheezy at least any indirectly linked external
> shared C++ libraries such as the Qt, libLASi, or wxwidgets libraries would
> transitively suck in a link to a shared version of libstdc++), but I was able to verify
> this problem on Debian wheezy when I tested a case of psttf alone where the libLASi
> library used by that device driver was statically built.
>
> The linking model I used for this analysis is stated in the commit message for
> a09dc18, and I have asked Andrew to review that.  But fundamentally what that
> commit does is to avoid comprehensive testing of PLplot components that satisfy the
> criteria when the linking model indicates the linking of the examples is problematic,
> i.e., the case of a traditional build of non-C or C++ examples for statically built
> libplplot where that library contains C++ code from any of the C++ devices).
>
> So regardless of the reliability of the linking model that motivates commit a09dc18,
> that commit should avoid the above f95 problem (since the ada, d, f95, java, and
> ocaml examples will not be built or tested for that special case).
>
> So when you get a chance, please try a comprehensive test again to see if the
> above commit allows that test to finally run to completion for the Cygwin platform for
> the case when the traditional build is included in the test.
>
> 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] Results of the comprehensive test on Cygwin

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]

>
> The first error message for the case of the traditional build of the f95 examples when
> PLplot was statically built was as follows:
>
> /cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(qt.cpp.o):qt.cpp
> :(.text+0x5cc0):
> undefined reference to std::ios_base::Init::Init()'
>
> std refers to symbols in the special library that the C++ compiler normally adds to the
> linking information (in this case the libstdc++ library that is associated with g++, but
> the name/location/version of that library might depend on which C++ compiler the
> user decides to use).  Of course, in this case we must link the Fortran examples with
> a Fortran compiler for the traditional build system for the installed example.
> Therefore, there is a linking error here because libstdc++ is obviously not
> automatically linked in by gfortran.  There are also similar potential problems for
> other non-C or C++ examples that are compiled.
>
Ah, that is indeed a familiar problem. If I understand it correctly, then C++ code requires a linker with libraries suitable for C++. Of course Fortran and other languages require their own libraries and it is usually the compiler (or the driver program) that adds the appropriate ones to the link step. One can get around this problem by explicitly supplying these libraries, but that is very much compiler-specific and even configuration-specific (for instance: under Windows the libraries for a debuggable program tend to be different than those for a release program).

I will give this new set-up a try. Since it is the computer which does most work, it should not be that time-consuming for me.

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.

Re: [Plplot-devel] A possible design of our new Fortran binding

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

Hi Alan, James,



In the attachment you will find a demonstration of the sort of Fortran bindings I have in mind. The essence is:

-        Use iso_c_binding to call the C functions directly (no intervening C wrapper if that can be avoided)

-        Use the renaming feature of the use statement to switch between single and double precision without code duplication. The result is that the bindings provide two versions, one for single-precision arguments and one for double-precision arguments, which are selected automatically by the compiler. (Mixtures of precisions within a single call are not supported - that would lead to a very akward combinatorics and I doubt this at all a practical use case.)

-        Hide those things like parameters that are not intended for the public interface. I will probably go and use "private" as the default and make the individual items public instead of what I have now (default "public" and hide the things that are not needed)

The source code currently is tuned to example x00f, slightly modified wrt the trunk. You can change the worknig precision parameter "wp" to select the other precision.

Notes:

-        newbinding.f90 is the topmost source file. All other files are included into it.

-        To link the example you need the PLplot C library. See the shell script "mk", which was set up for Cygwin

-        With slight modifications this should work on Linux too (there you can use the libplplot.so shared object directly).

-        I have not tested this with command-line arguments yet - that is the trickier part of the code.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, May 17, 2015 7:00 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: A possible design of our new Fortran binding
>
> On 2015-05-17 07:38-0000 Arjen Markus wrote:
>
> > My new bindings would not have prevented this [argument kind error], as it was an
> omission, not an incorrect implementation.
>
> Hi Arjen:
>
> This is an important point that I think needs more discussion because the new
> Fortran binding for ephcom very much prevents such issues from happening.
>
> There I completely dropped all C code and C headers that helped define the old
> fortran binding (the ephcom equivalent to PLplot's plstubs.h, sc3d.c, sccont.c, and
> scstubs.c).  Instead, I used the features of the iso_c_binding module to write the
> interface virtually entirely in Fortran (except for the few cases where iso_c_binding
> did not have some argument processing feature that I had to write from scratch in C).
> So if I had omitted something from the Fortran interface.f90 file, there was no leftover
> C infrastructure that would silently generate a f77 fallback.  Instead, the omission
> would be immediately detected when I attempted to use the missing function.
>
> I am pretty sure it should be possible (since argument transformations from single to
> double or double to single is the only extra
> requirement) to do the same thing for our new Fortran interface.  To make that
> specific, I think our first goal should be to write an
> interface.f90 file that contains complete information to handle single or double
> precision versions of x00f.f90 with no C code required at all to define the interface.
>
> If you agree, then once that first goal is achieved (again with plstubs.h, sc3d.c,
> sccont.c, and scstubs.c removed), we should be able to expand the interface (using
> a C layer where necessary for processing special kinds of arguments) to handle
> standard examples that include use of more complicated PLplot arguments.
>
> 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] Results of the comprehensive test on Cygwin

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

On 2015-05-18 08:17-0000 Arjen Markus wrote:

> Please find the results of the comprehensive test on Cygwin using
the latest version. It fails in the static build, using the installed
examples, but the other configurations seem fine. So we are making
progress. What is going wrong with the installed examples is, however,
a mystery to me.

The first error message for the case of the traditional build of the f95 examples
when PLplot was statically built was as follows:

/cygdrive/d/plplot-svn/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(qt.cpp.o):qt.cpp:(.text+0x5cc0):
undefined reference to std::ios_base::Init::Init()'

std refers to symbols in the special library that the C++ compiler
normally adds to the linking information (in this case the libstdc++
library that is associated with g++, but the name/location/version of
that library might depend on which C++ compiler the user decides to
use).  Of course, in this case we must link the Fortran examples with
a Fortran compiler for the traditional build system for the installed
example.  Therefore, there is a linking error here because libstdc++
is obviously not automatically linked in by gfortran.  There are also
similar potential problems for other non-C or C++ examples that are
compiled.

It took some doing (because on Debian wheezy at least any indirectly
linked external shared C++ libraries such as the Qt, libLASi, or
wxwidgets libraries would transitively suck in a link to a shared
version of libstdc++), but I was able to verify this problem on Debian
wheezy when I tested a case of psttf alone where the libLASi library
used by that device driver was statically built.

The linking model I used for this analysis is stated in the commit
message for a09dc18, and I have asked Andrew to review that.  But
fundamentally what that commit does is to avoid comprehensive testing
of PLplot components that satisfy the criteria when the linking model
indicates the linking of the examples is problematic, i.e., the case
of a traditional build of non-C or C++ examples for statically built
libplplot where that library contains C++ code from any of the C++
devices).

So regardless of the reliability of the linking model that motivates
commit a09dc18, that commit should avoid the above f95 problem
(since the ada, d, f95, java, and ocaml examples will not be built or
tested for that special case).

So when you get a chance, please try a comprehensive test again to see
if the above commit allows that test to finally run to completion for
the Cygwin platform for the case when the traditional build is
included in the test.

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] Linking model review requested

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

Hi Andrew:

Would you please take a quick look at the commit message for a09dc18?
In that commit message I outline the linking model I used to draw the
conclusion that the ada, d, f95, java, and ocaml traditional examples
builds were going to _sometimes_ fail for a certain combination of
circumstances (static PLplot build with at least one of the C++ device
drivers enabled).

I am asking for that review because I hate to give up all those
components of the comprehensive test of the traditional build for the
given circumstances if I don't have to.  I am pretty sure your review
of the linking model I use will show I am right, but nevertheless that
review would be much appreciated since it would help to put my mind at
ease about this commit (which disables the relevant parts of the
comprehensive test for the given combination of circumstances).

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] Question about Ada support

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

On 2015-05-20 14:12-0400 Tom Kacvinsky wrote:

> I figured it out.  One need only set CMAKE_Ada_COMPILER_INIT to a list of
> fully qualified paths to the gcc/gnatgcc one wants.

Hi Tom:

I am glad you figured it out because I could not do that myself.

And thanks for sharing the solution which should help others here who
need to distinguish between the gcc compiler used by Ada and by C.

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] Question about Ada support

[Tom K. <tom...@ve...>]

I figured it out.  One need only set CMAKE_Ada_COMPILER_INIT to a list of
fully qualified paths to the gcc/gnatgcc one wants.

On Wed, May 20, 2015 at 1:17 PM, Tom Kacvinsky <tom...@ve...
> wrote:

>
>
> On Tue, May 19, 2015 at 7:22 PM, Alan W. Irwin <ir...@be...>
> wrote:
>
>> On 2015-05-19 13:20-0400 Tom Kacvinsky wrote:
>>
>>  Alan,
>>>
>>> This is not in regards to plplot proper, but rather the cmake Ada support
>>> bundled with plplot.
>>>
>>> How is add_executable supposed to work?  Does it invoke gcc for each
>>> adb/ads file, then call the rest of the GNAT tool chain utilities to
>>> generate an executable, or does it just invoke gnatmake?  the reason I
>>> ask
>>> is that we aren't listing all of the Ada files necessary to build the
>>> executable, but all of the necessary files end up getting compiled.  But
>>> upon a subsequent build, not all Ada files get recompiled, even if
>>> they've
>>> changed.  I am thinking if gnatmake is used, this change would be
>>> detected
>>> and the right thing would happen.
>>>
>>> So, should I be listing all of the necessary Ada files in the
>>> add_executable(<target> <files>) invocation so that no matter what is
>>> used
>>> under the hood, recompiles happen when necessary.
>>>
>>
>> Hi Tom:
>>
>> From memory I am pretty sure that gnatmake is used under the hood for
>> the add_executable case.  But the thing to do is to run
>>
>> make VERBOSE=1
>>
>> (or verbose equivalent if you are building with a non-make generator) to
>> see exactly what commands are being used for the Ada executable build.
>>
>> And to answer your last question, I am virtually positive you should
>> mention all necessary Ada source files in the add_executable(<target>
>> <files>) invocation because that is the way add_excutable is supposed
>> to work in general.  But to figure it out for sure try with and
>> without mentioning all Ada source files for VERBOSE=1 to see the
>> exact difference that makes to the build.
>>
>> Sorry that I am being a little vague here, but our own use of Ada
>> language support only uses single files in the add_executable command
>> so I don't know exactly what would happen for multiple files.
>> Furthermore, it has been a very long while since I worked on our Ada
>> language support, and when I implemented that I had very little
>> understanding of CMake language support (and that is still the case).
>> So I converted existing language support for C over to Ada language
>> support using trial and error methods using tests like I suggested
>> above to evaluate whether the results were good enough for our needs.
>> And stopped when that was finally the case.
>>
>
> Hi again Alan,
>
> I made the changes to add_executable and it appears gnatmake is not
> invoked to build the executable, at least not that I can tell with "make
> VERBOSE=1".  gcc is getting invoked to make object files from the Ada
> source, but the problem I am now running into is that cmake is now using
> the system gcc to compile the files, where we want a different gcc to be
> used.  IS there a way of telling the cmake Ada support to use a different
> gcc (like there is for C, C++ and FORTRAN compilers)?  I am talking about
> tricks with cmake variables, not the PATH setting (as then the gcc that we
> want for Ada would be used for C/C++, and for those compiles, we want a
> different gcc).
>
> Thanks,
>
> Tom
>

Re: [Plplot-devel] Question about Ada support

[Tom K. <tom...@ve...>]

On Tue, May 19, 2015 at 7:22 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-05-19 13:20-0400 Tom Kacvinsky wrote:
>
>  Alan,
>>
>> This is not in regards to plplot proper, but rather the cmake Ada support
>> bundled with plplot.
>>
>> How is add_executable supposed to work?  Does it invoke gcc for each
>> adb/ads file, then call the rest of the GNAT tool chain utilities to
>> generate an executable, or does it just invoke gnatmake?  the reason I ask
>> is that we aren't listing all of the Ada files necessary to build the
>> executable, but all of the necessary files end up getting compiled.  But
>> upon a subsequent build, not all Ada files get recompiled, even if they've
>> changed.  I am thinking if gnatmake is used, this change would be detected
>> and the right thing would happen.
>>
>> So, should I be listing all of the necessary Ada files in the
>> add_executable(<target> <files>) invocation so that no matter what is used
>> under the hood, recompiles happen when necessary.
>>
>
> Hi Tom:
>
> From memory I am pretty sure that gnatmake is used under the hood for
> the add_executable case.  But the thing to do is to run
>
> make VERBOSE=1
>
> (or verbose equivalent if you are building with a non-make generator) to
> see exactly what commands are being used for the Ada executable build.
>
> And to answer your last question, I am virtually positive you should
> mention all necessary Ada source files in the add_executable(<target>
> <files>) invocation because that is the way add_excutable is supposed
> to work in general.  But to figure it out for sure try with and
> without mentioning all Ada source files for VERBOSE=1 to see the
> exact difference that makes to the build.
>
> Sorry that I am being a little vague here, but our own use of Ada
> language support only uses single files in the add_executable command
> so I don't know exactly what would happen for multiple files. Furthermore,
> it has been a very long while since I worked on our Ada
> language support, and when I implemented that I had very little
> understanding of CMake language support (and that is still the case).
> So I converted existing language support for C over to Ada language
> support using trial and error methods using tests like I suggested
> above to evaluate whether the results were good enough for our needs.
> And stopped when that was finally the case.
>

Hi again Alan,

I made the changes to add_executable and it appears gnatmake is not invoked
to build the executable, at least not that I can tell with "make
VERBOSE=1".  gcc is getting invoked to make object files from the Ada
source, but the problem I am now running into is that cmake is now using
the system gcc to compile the files, where we want a different gcc to be
used.  IS there a way of telling the cmake Ada support to use a different
gcc (like there is for C, C++ and FORTRAN compilers)?  I am talking about
tricks with cmake variables, not the PATH setting (as then the gcc that we
want for Ada would be used for C/C++, and for those compiles, we want a
different gcc).

Thanks,

Tom

Re: [Plplot-devel] Question about Ada support

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

On 2015-05-19 13:20-0400 Tom Kacvinsky wrote:

> Alan,
>
> This is not in regards to plplot proper, but rather the cmake Ada support
> bundled with plplot.
>
> How is add_executable supposed to work?  Does it invoke gcc for each
> adb/ads file, then call the rest of the GNAT tool chain utilities to
> generate an executable, or does it just invoke gnatmake?  the reason I ask
> is that we aren't listing all of the Ada files necessary to build the
> executable, but all of the necessary files end up getting compiled.  But
> upon a subsequent build, not all Ada files get recompiled, even if they've
> changed.  I am thinking if gnatmake is used, this change would be detected
> and the right thing would happen.
>
> So, should I be listing all of the necessary Ada files in the
> add_executable(<target> <files>) invocation so that no matter what is used
> under the hood, recompiles happen when necessary.

Hi Tom:

>From memory I am pretty sure that gnatmake is used under the hood for
the add_executable case.  But the thing to do is to run

make VERBOSE=1

(or verbose equivalent if you are building with a non-make generator) to
see exactly what commands are being used for the Ada executable build.

And to answer your last question, I am virtually positive you should
mention all necessary Ada source files in the add_executable(<target>
<files>) invocation because that is the way add_excutable is supposed
to work in general.  But to figure it out for sure try with and
without mentioning all Ada source files for VERBOSE=1 to see the
exact difference that makes to the build.

Sorry that I am being a little vague here, but our own use of Ada
language support only uses single files in the add_executable command
so I don't know exactly what would happen for multiple files. 
Furthermore, it has been a very long while since I worked on our Ada
language support, and when I implemented that I had very little
understanding of CMake language support (and that is still the case).
So I converted existing language support for C over to Ada language
support using trial and error methods using tests like I suggested
above to evaluate whether the results were good enough for our needs.
And stopped when that was finally the case.

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] Question about Ada support

[Tom K. <tom...@ve...>]

Alan,

This is not in regards to plplot proper, but rather the cmake Ada support
bundled with plplot.

How is add_executable supposed to work?  Does it invoke gcc for each
adb/ads file, then call the rest of the GNAT tool chain utilities to
generate an executable, or does it just invoke gnatmake?  the reason I ask
is that we aren't listing all of the Ada files necessary to build the
executable, but all of the necessary files end up getting compiled.  But
upon a subsequent build, not all Ada files get recompiled, even if they've
changed.  I am thinking if gnatmake is used, this change would be detected
and the right thing would happen.

So, should I be listing all of the necessary Ada files in the
add_executable(<target> <files>) invocation so that no matter what is used
under the hood, recompiles happen when necessary.

Thanks,

Tom

Re: [Plplot-devel] Fedora plplot patches

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

On 2015-05-18 17:41-0700 Alan W. Irwin wrote:

> [...]So really
> the definitive test of that result is do the ocaml examples build and
> run fine for you with that null string -ccopt option for the
> traditional build of installed examples or does the OCaml compiler
> choke on that null string?  Run "make noninteractive >&
> noninteractive.out" in $prefix/share/plplot5.11.0/examples to find
> out.

Gack!  Of course, that should read

make test_noninteractive >& test_noninteractive.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] Incorrect pkg-config link flags with plplot 5.11.0

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

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
__________________________

Re: [Plplot-devel] Fedora plplot patches

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

On 2015-05-18 16:53-0600 Orion Poplawski wrote:

> On 05/18/2015 01:35 AM, Alan W. Irwin wrote:
[...]
>> On 2015-04-25 12:42-0600 Orion Poplawski wrote:
>>
>>> 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.
>>
>> Patch2a: PKG_CONFIG_ENV
>>
>> I have now (commit id 2b4e397) implemented a user-configurable location called
>> CMAKE_INSTALL_PKG_CONFIG_DIR where the PLplot *.pc files are
>> installed.  The default value for this cached variable is
>>
>> $prefix/share/pkgconfig
>>
>> which is apparently what Debian wheezy uses for multiarch *.pc files.
>>
>> @Andrew: can you confirm that location for modern Debian?
>>
>> @Orion: If that default location is not right for the Fedora multiarch
>> needs, try setting CMAKE_INSTALL_PKG_CONFIG_DIR on the cmake command
>> line.
>
> *If* the pkgconfig files were "multiarch"/noarch, that would be the place to
> install them.  However, they are not noarch - they contain /usr/lib or
> /usr/lib64 depending on the architecture:
>
[...]
> plplot.pc:libdir=/usr/lib64
> plplot.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
> plplot.pc:Libs.private: -L"${libdir}" -L"/usr/lib64" -lltdl -L"/usr/lib64" -lm
> -L"/usr/lib64" -lshp -L"/usr/lib64" -lfreetype -lcsirocsa -lcsironn -lqhull
> -lqsastime
[...]

OK. Thanks for reminding me that these *.pc files are arch-dependent.
I don't know what I was thinking.

But it also appears that Fedora and Debian disagree here concerning
library install locations; Fedora uses
/usr/lib or /usr/lib64 while Debian uses
/usr/lib/i386-linux-gnu or /usr/lib/x86_64-linux-gnu.

Currently, our CMake build system model sets the default library
location with (in cmake/modules/instdirs/cmake)

set(
CMAKE_INSTALL_LIBDIR
${CMAKE_INSTALL_EXEC_PREFIX}/lib
CACHE PATH "install location for object code libraries"
)

Since that default satisfies neither Andrew's or your needs I assume you both
have to override CMAKE_INSTALL_LIBDIR.  In fact, Andrew (from
debian/rules) overrides it with
-DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
and I assume you have to do something similar in your spec file.

Therefore, to make life more convenient for you both I have used

set(
CMAKE_INSTALL_PKG_CONFIG_DIR
${CMAKE_INSTALL_LIBDIR}/pkgconfig
CACHE PATH "install location for pkg-config *.pc files"
)

for the pkg-config default install directory
in my latest commit (3062c3b).  Which implies if you override
CMAKE_INSTALL_LIBDIR, then CMAKE_INSTALL_PKG_CONFIG_DIR automatically
gets overridden as well so you don't have to override it separately. 
So please try again with that commit to see if it satisfies your
needs.

> In the Makefiles I get:
>

[...]
> ocaml/Makefile:RPATHCMD = -ccopt ''
>
> Is that right?

Well, I double checked and that is indeed the expected result if
-DUSE_RPATH=OFF.  However, I don't comprehensively build- or run-test
-DUSE_RPATH=OFF here (I have enough such testing on my plate already
with default -DUSE_RPATH=ON), and instead leave such testing to
distribution packagers who really do need -DUSE_RPATH=OFF. So really
the definitive test of that result is do the ocaml examples build and
run fine for you with that null string -ccopt option for the
traditional build of installed examples or does the OCaml compiler
choke on that null string?  Run "make noninteractive >&
noninteractive.out" in $prefix/share/plplot5.11.0/examples to find
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] Incorrect pkg-config link flags with plplot 5.11.0

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

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.

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.

I don't seem to be getting Qt examples installed so I can't test.

Otherwise looks much better, thanks!

- Orion

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

Re: [Plplot-devel] Fedora plplot patches

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

On 05/18/2015 01:35 AM, Alan W. Irwin wrote:
> Hi Hez:
> 
> Can you evaluate Patch7 below that removes the -custom option
> from our ocamlc build commands?
> 
> @Orion and Andrew: the rest of this response is addressed to you
> as our respective Fedora and Debian packagers.
> 
> On 2015-04-25 12:42-0600 Orion Poplawski wrote:
> 
>> 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.
> 
> Patch2a: PKG_CONFIG_ENV
> 
> I have now (commit id 2b4e397) implemented a user-configurable location called
> CMAKE_INSTALL_PKG_CONFIG_DIR where the PLplot *.pc files are
> installed.  The default value for this cached variable is
> 
> $prefix/share/pkgconfig
> 
> which is apparently what Debian wheezy uses for multiarch *.pc files.
> 
> @Andrew: can you confirm that location for modern Debian?
> 
> @Orion: If that default location is not right for the Fedora multiarch
> needs, try setting CMAKE_INSTALL_PKG_CONFIG_DIR on the cmake command
> line.

*If* the pkgconfig files were "multiarch"/noarch, that would be the place to
install them.  However, they are not noarch - they contain /usr/lib or
/usr/lib64 depending on the architecture:

plplot-ada.pc:libdir=/usr/lib64
plplot-ada.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-ada.pc:Libs.private: -L"${libdir}" -L"/usr/lib64" -lgnat-5
plplot-c++.pc:libdir=/usr/lib64
plplot-c++.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-f95.pc:libdir=/usr/lib64
plplot-f95.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-f95.pc:Cflags: -I"${includedir}" -I"/usr/lib64/gfortran/modules"
plplot-ocaml.pc:libdir=/usr/lib64
plplot-ocaml.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot.pc:libdir=/usr/lib64
plplot.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot.pc:Libs.private: -L"${libdir}" -L"/usr/lib64" -lltdl -L"/usr/lib64" -lm
-L"/usr/lib64" -lshp -L"/usr/lib64" -lfreetype -lcsirocsa -lcsironn -lqhull
-lqsastime
plplot-qt.pc:libdir=/usr/lib64
plplot-qt.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-qt.pc:Libs: -L"${libdir}" -lplplotqt  -L"/usr/lib64" -lQtSvg
-L"/usr/lib64" -lQtGui -L"/usr/lib64" -lQtCore
plplot-qt.pc:Libs.private: -L"${libdir}" -lplplot -L"/usr/lib64" -lm
plplot-tcl_Main.pc:libdir=/usr/lib64
plplot-tcl_Main.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-tcl_Main.pc:Libs.private: -L"${libdir}" -lplplot -L"/usr/lib64" -ltcl
-L"/usr/lib64" -ltk
plplot-tcl.pc:libdir=/usr/lib64
plplot-tcl.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-tcl.pc:Libs.private: -L"${libdir}" -lplplot -ltclmatrix -L"/usr/lib64"
-ltcl -L"/usr/lib64" -ltk
plplot-wxwidgets.pc:libdir=/usr/lib64
plplot-wxwidgets.pc:drvdir=/usr/lib64/plplot5.11.0/drivers
plplot-wxwidgets.pc:Libs.private: -L"${libdir}" -lplplot -lplplotcxx -pthread
-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L"/usr/lib64"
-lwx_baseu-2.8 -L"/usr/lib64" -lwx_gtk2u_core-2.8
plplot-wxwidgets.pc:Cflags: -I"${includedir}" -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -D__WXGTK__ -I/usr/lib64/wx/include/gtk2-unicode-release-2.8
-I/usr/include/wx-2.8

But I can set CMAKE_INSTALL_PKG_CONFIG_DIR if absolutely necessary.  Debian
appears to use:

/usr/lib/i386-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig

So this change is almost certainly incorrect.

> 
> Patch2b: RPATH
> 
> Use -DUSE_RPATH=OFF.  This should make all rpath results empty and the
> RPATH part of Patch2 redundant.
> 
> @Orion:
> In sum, with commit id 2b4e397 and the long-implemented USE_RPATH there
> should no longer be any need for Patch2.  Please confirm that.

In the Makefiles I get:

PKG_CONFIG_ENV =
PKG_CONFIG_PATH="/usr/share/pkgconfig::/usr/lib64/pkgconfig:/usr/share/pkgconfig"
RPATHCMD =

So RPATHCMD looks mostly okay, however:

ocaml/Makefile:RPATHCMD = -ccopt ''

Is that right?

But PKG_CONFIG_ENV still contains arch specific info.


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

Re: [Plplot-devel] [PATCH] OS X pkg-config.cmake error: string REGEX REPLACE needs 6 arguments

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

On 2015-04-17 10:31-0500 J. Lewis Muir wrote:

> Hello!
>
> When configuring PLplot 5.11.0 from pkgsrc using my own pkgsrc plplot
> package definition on OS X Yosemite using CMake 3.0.2, I get the
> following error:
>
> ===
> CMake Error at cmake/modules/pkg-config.cmake:202 (string):
>  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
>  command.
> Call Stack (most recent call first):
>  cmake/modules/pkg-config.cmake:355 (pkg_config_link_flags)
>  bindings/c++/CMakeLists.txt:83 (pkg_config_file)
> ===

Hi Lewis:

We prefer issues first to be discussed either here or on
plplot-general (because the issues often turn out not to be bugs or
can be fixed immediately with no bug triage or have already been fixed
in our git version).  Then as a last resort post the issue to the bug
tracker.  Thanks very much for following that preferred reporting
model.  But somehow that model broke down and the report you made
above just slipped through here with no response from anybody so you
did have to resort to using the bug tracker. Sorry about that!

I am pretty sure I have already fixed the above problem as part of
my large recent effort to make the pkg-config linking model analogous
to the much better debugged CMake linking model for PLplot.

So could you give the latest version of our git master branch
(which will soon form the basis for the forthcoming 5.11.1 release)
a try to see if that solves the above issue?  If so I
will close the corresponding bug report that you just made at
<http://sourceforge.net/p/plplot/bugs/163/>.

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] PDL-Graphics-PLplot and plplot 5.11.0

[Doug H. <dh...@uc...>]

Hi Orion:  I put a new version of PDL-Graphics-PLplot (v 0.71)  on CPAN 
that does something
similar.  I think my update is a bit cleaner.

Regards,

   Doug


On 05/18/15 13:56, Orion Poplawski wrote:
> You can check here:
>
> http://pkgs.fedoraproject.org/cgit/perl-PDL-Graphics-PLplot.git/log/
>
> for what the Fedora packager did for 5.11.0 support.
>
> On 04/24/2015 05:41 PM, Doug Hunt wrote:
>> Hi Orion:  Thanks for the patch.  I'll look into this next week and try to put
>> out
>> an updated PDL-Graphics-PLplot.
>>
>> Regards,
>>
>>    Doug Hunt
>>
>> On 04/24/15 16:34, Orion Poplawski wrote:
>>> I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0.  First I need
>>> the attached patch to handle the name change.
>>>
>>> Next issue I'm running into is the plplot.t test segfaulting:
>>>
>>> $ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
>>> GNU gdb (GDB) Fedora 7.9-11.fc23
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from perl...Reading symbols from
>>> /home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
>>>
>>> debugging symbols found)...done.
>>> (no debugging symbols found)...done.
>>> Missing separate debuginfos, use: dnf debuginfo-install
>>> perl-5.20.2-328.fc23.x86_64
>>> (gdb) run -I../blib/lib ./plplot.t
>>> Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Detaching after fork from child process 26859.
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>>>       at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>>> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>>> *) plsc, op );
>>> (gdb) bt
>>> #0  0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>>>       at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>>> #1  0x00007ffff2ff4e84 in c_plschr (def=<optimized out>, scale=<optimized out>)
>>>       at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
>>> #2  0x00007ffff32e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at
>>> PLplot.xs:11154
>>> #3  0x00007ffff55a6194 in pdl.ensure_trans ()
>>>      from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>>> #4  0x00007ffff55a5150 in pdl_make_trans_mutual ()
>>>      from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>>> #5  0x00007ffff32ababf in XS_PDL_plschr (my_perl=<optimized out>,
>>> cv=<optimized out>)
>>>       at PLplot.xs:50441
>>> #6  0x00007ffff7aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
>>> #7  0x00007ffff7ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
>>> #8  0x00007ffff7a729c0 in perl_run () from /lib64/libperl.so.5.20
>>> #9  0x0000000000400d79 in main ()
>>> (gdb) list
>>> 255             plbuf_state( plsc, op );
>>> 256
>>> 257         save_locale = plsave_set_locale();
>>> 258         if ( !plsc->stream_closed )
>>> 259         {
>>> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>>> *) plsc, op );
>>> 261         }
>>> 262         plrestore_locale( save_locale );
>>> 263     }
>>> 264
>>> (gdb) print plsc
>>> $1 = (PLStream *) 0x7ffff321eaa0 <pls0>
>>> (gdb) print op
>>> $2 = 7
>>> (gdb) print plsc->dispatch_table
>>> $3 = (PLDispatchTable *) 0x0
>>> (gdb) print *plsc
>>> $2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
>>> dev_initialized = 0,
>>>     program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
>>> icol0 = 0,
>>>     ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
>>> cmap1_max = 0,
>>>     curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
>>> tmpcolor = {
>>>       r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
>>> 0x155e310,
>>>     cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
>>>         alt_hue_path = 0} <repeats 256 times>}, width = 0, widthset = 0,
>>> widthlock = 0,
>>>     arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0, dispatch_table
>>> = 0x0,
>>>     plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
>>> graphx = 0,
>>>     nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
>>> fflen = 0,
>>>     bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0,
>>> dev_di = 0,
>>>     dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
>>> dev_fastimg = 0,
>>>     dev_arc = 0, DevName = "xfig", '\000' <repeats 75 times>, OutFile = 0x0,
>>>     BaseName = 0x151a800 "test2.xfig", FileName = 0x155e2d0 "test2.xfig",
>>> output_type = 0,
>>>     bytecnt = 0, page = 0, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0,
>>> dev_y = 0x0,
>>>     dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0,
>>> dev_zmin = 0,
>>>     dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev
>>> = 0x0,
>>>     dev_data = 0x0, KeyEH = 0x0, KeyEH_data = 0x0, ButtonEH = 0x0, ButtonEH_data
>>> = 0x0,
>>>     LocateEH = 0x0, LocateEH_data = 0x0, bop_handler = 0x0, bop_data = 0x0,
>>> eop_handler = 0x0,
>>>     eop_data = 0x0, xdpi = 0, ydpi = 0, xlength = 0, ylength = 0, xoffset = 0,
>>> yoffset = 0,
>>>     pageset = 0, hack = 0, tidy = 0x0, tidy_data = 0x0, errcode = 0x0, errmsg
>>> = 0x0,
>>>     geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0,
>>> server_name = 0x0,
>>>     server_host = 0x0, server_port = 0x0, user = 0x0, plserver = 0x0, plwindow =
>>> 0x0,
>>>     auto_path = 0x0, tk_file = 0x0, bufmax = 0, dp = 0, server_nokill = 0,
>>>     plbuf_buffer_grow = 0, plbuf_buffer_size = 0, plbuf_buffer = 0x0,
>>> plbuf_top = 0,
>>>     plbuf_readpos = 0, plbufOwner = 0, difilt = 0, diclpxmi = 0, diclpxma = 0,
>>> diclpymi = 0,
>>>     diclpyma = 0, dipxmin = 0, dipymin = 0, dipxmax = 0, dipymax = 0, dipxax =
>>> 0, dipxb = 0,
>>>     dipyay = 0, dipyb = 0, aspdev = 0, aspect = 0, aspori = 0, caspfactor = 0,
>>> mar = 0, jx = 0,
>>>     jy = 0, didxax = 0, didxb = 0, didyay = 0, didyb = 0, diorot = 0, dioxax =
>>> 0, dioxay = 0,
>>>     dioxb = 0, dioyax = 0, dioyay = 0, dioyb = 0, dimxax = 0, dimxb = 0, dimyay
>>> = 0, dimyb = 0,
>>>     dimxmin = 0, dimymin = 0, dimxmax = 0, dimymax = 0, dimxpmm = 0, dimypmm
>>> = 0,
>>>     page_status = 0, freeaspect = 0, portrait = 0, patt = 0, inclin = {0, 0},
>>> delta = {0, 0},
>>>     nps = 0, currx = 0, curry = 0, mark = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, space
>>> = {0, 0, 0, 0,
>>>       0, 0, 0, 0, 0, 0}, nms = 0, timecnt = 0, alarm = 0, pendn = 0, curel = 0,
>>> esc = 0 '\000',
>>>     scale = 0, chrdef = 0, chrht = 0, symdef = 0, symht = 0, majdef = 0, majht =
>>> 0, mindef = 0,
>>>     minht = 0, setpre = 0, precis = 0, xdigmax = 0, ydigmax = 0, zdigmax = 0,
>>> xdigits = 0,
>>>     ydigits = 0, zdigits = 0, timefmt = 0x0, label_func = 0x0, label_data = 0x0,
>>> vppxmi = 0,
>>>     vppxma = 0, vppymi = 0, vppyma = 0, sppxmi = 0, sppxma = 0, sppymi = 0,
>>> sppyma = 0,
>>>     clpxmi = 0, clpxma = 0, clpymi = 0, clpyma = 0, phyxmi = 0, phyxma = 0,
>>> phyxlen = 0,
>>>     phyymi = 0, phyyma = 0, phyylen = 0, umx = 0, umy = 0, xpmm = 0, ypmm = 0,
>>> base3x = 0,
>>>     base3y = 0, basecx = 0, basecy = 0, domxmi = 0, domxma = 0, domymi = 0,
>>> domyma = 0,
>>>     zzscl = 0, ranmi = 0, ranma = 0, cxx = 0, cxy = 0, cyx = 0, cyy = 0, cyz =
>>> 0, czx = 0,
>>>     czy = 0, czz = 0, nplwin = 0, plwin = {{dxmi = 0, dxma = 0, dymi = 0, dyma =
>>> 0, wxmi = 0,
>>>         wxma = 0, wymi = 0, wyma = 0} <repeats 64 times>}, nsubx = 0, nsuby = 0,
>>> cursub = 0,
>>>     spdxmi = 0, spdxma = 0, spdymi = 0, spdyma = 0, vpdxmi = 0, vpdxma = 0,
>>> vpdymi = 0,
>>>     vpdyma = 0, vpwxmi = 0, vpwxma = 0, vpwymi = 0, vpwyma = 0, wpxscl = 0,
>>> wpxoff = 0,
>>>     wpyscl = 0, wpyoff = 0, wmxscl = 0, wmxoff = 0, wmyscl = 0, wmyoff = 0,
>>> wdxscl = 0,
>>>     wdxoff = 0, wdyscl = 0, wdyoff = 0, dev_compression = 0, cfont = 0, FT =
>>> 0x0,
>>>     plPlotterPtr = 0x0, dev_unicode = 0, alt_unicode = 0, fci = 0,
>>> dev_hrshsym = 0,
>>>     original_chrdef = 0, original_chrht = 0, psdoc = 0x0, qsasconfig = 0x0,
>>> dev_gradient = 0,
>>>     ngradient = 0, xgradient = 0x0, ygradient = 0x0, n_polygon = 0, x_polygon
>>> = 0x0,
>>>     y_polygon = 0x0, stream_closed = 0, line_style = 0, dev_mem_alpha = 0,
>>>     has_string_length = 0, string_length = 0, get_string_length = 0,
>>> dev_eofill = 0,
>>>     dev_modeset = 0, if_boxbb = 0, boxbb_xmin = 0, boxbb_xmax = 0, boxbb_ymin
>>> = 0,
>>>     boxbb_ymax = 0, mf_infile = 0x0, mf_outfile = 0x0}
>>>
>>>
>>> This seems to happen right away:
>>>
>>> use PDL;
>>> use PDL::Config;
>>> use PDL::Graphics::PLplot;
>>> use Test::More qw(no_plan);
>>>
>>> # Use xfig driver because it should always be installed.
>>> #my $dev = 'png';
>>> my $dev = 'xfig';
>>>
>>> # redirect STDERR to purge silly 'opened *.xfig' messages
>>> my ($pl, $x, $y, $min, $max, $oldwin, $nbins);
>>>
>>> ###
>>> # Initial test to work around font file brain damage:  for some kinds of
>>> # PLplot errors, control never returns to us.  FMH.
>>> #   --CED
>>> ###
>>>
>>> my $tmpdir  = $PDL::Config{TEMPDIR} || "/tmp";
>>> my $tmpfile = $tmpdir . "/foo$$.$dev";
>>>
>>> $pl = PDL::Graphics::PLplot->new (DEV => $dev,
>>>                                     FILE => "test2.$dev",
>>>                                     BACKGROUND => [255,255,255]);
>>>
>>>
>>> Anything else to look for?
>>>
>>>
>

Re: [Plplot-devel] PDL-Graphics-PLplot and plplot 5.11.0

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

You can check here:

http://pkgs.fedoraproject.org/cgit/perl-PDL-Graphics-PLplot.git/log/

for what the Fedora packager did for 5.11.0 support.

On 04/24/2015 05:41 PM, Doug Hunt wrote:
> Hi Orion:  Thanks for the patch.  I'll look into this next week and try to put
> out
> an updated PDL-Graphics-PLplot.
> 
> Regards,
> 
>   Doug Hunt
> 
> On 04/24/15 16:34, Orion Poplawski wrote:
>> I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0.  First I need
>> the attached patch to handle the name change.
>>
>> Next issue I'm running into is the plplot.t test segfaulting:
>>
>> $ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
>> GNU gdb (GDB) Fedora 7.9-11.fc23
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/>.
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from perl...Reading symbols from
>> /home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
>>
>> debugging symbols found)...done.
>> (no debugging symbols found)...done.
>> Missing separate debuginfos, use: dnf debuginfo-install
>> perl-5.20.2-328.fc23.x86_64
>> (gdb) run -I../blib/lib ./plplot.t
>> Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Detaching after fork from child process 26859.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>>      at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>> *) plsc, op );
>> (gdb) bt
>> #0  0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>>      at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>> #1  0x00007ffff2ff4e84 in c_plschr (def=<optimized out>, scale=<optimized out>)
>>      at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
>> #2  0x00007ffff32e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at
>> PLplot.xs:11154
>> #3  0x00007ffff55a6194 in pdl.ensure_trans ()
>>     from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>> #4  0x00007ffff55a5150 in pdl_make_trans_mutual ()
>>     from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>> #5  0x00007ffff32ababf in XS_PDL_plschr (my_perl=<optimized out>,
>> cv=<optimized out>)
>>      at PLplot.xs:50441
>> #6  0x00007ffff7aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
>> #7  0x00007ffff7ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
>> #8  0x00007ffff7a729c0 in perl_run () from /lib64/libperl.so.5.20
>> #9  0x0000000000400d79 in main ()
>> (gdb) list
>> 255             plbuf_state( plsc, op );
>> 256
>> 257         save_locale = plsave_set_locale();
>> 258         if ( !plsc->stream_closed )
>> 259         {
>> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>> *) plsc, op );
>> 261         }
>> 262         plrestore_locale( save_locale );
>> 263     }
>> 264
>> (gdb) print plsc
>> $1 = (PLStream *) 0x7ffff321eaa0 <pls0>
>> (gdb) print op
>> $2 = 7
>> (gdb) print plsc->dispatch_table
>> $3 = (PLDispatchTable *) 0x0
>> (gdb) print *plsc
>> $2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
>> dev_initialized = 0,
>>    program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
>> icol0 = 0,
>>    ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
>> cmap1_max = 0,
>>    curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
>> tmpcolor = {
>>      r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
>> 0x155e310,
>>    cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
>>        alt_hue_path = 0} <repeats 256 times>}, width = 0, widthset = 0,
>> widthlock = 0,
>>    arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0, dispatch_table
>> = 0x0,
>>    plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
>> graphx = 0,
>>    nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
>> fflen = 0,
>>    bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0,
>> dev_di = 0,
>>    dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
>> dev_fastimg = 0,
>>    dev_arc = 0, DevName = "xfig", '\000' <repeats 75 times>, OutFile = 0x0,
>>    BaseName = 0x151a800 "test2.xfig", FileName = 0x155e2d0 "test2.xfig",
>> output_type = 0,
>>    bytecnt = 0, page = 0, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0,
>> dev_y = 0x0,
>>    dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0,
>> dev_zmin = 0,
>>    dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev
>> = 0x0,
>>    dev_data = 0x0, KeyEH = 0x0, KeyEH_data = 0x0, ButtonEH = 0x0, ButtonEH_data
>> = 0x0,
>>    LocateEH = 0x0, LocateEH_data = 0x0, bop_handler = 0x0, bop_data = 0x0,
>> eop_handler = 0x0,
>>    eop_data = 0x0, xdpi = 0, ydpi = 0, xlength = 0, ylength = 0, xoffset = 0,
>> yoffset = 0,
>>    pageset = 0, hack = 0, tidy = 0x0, tidy_data = 0x0, errcode = 0x0, errmsg
>> = 0x0,
>>    geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0,
>> server_name = 0x0,
>>    server_host = 0x0, server_port = 0x0, user = 0x0, plserver = 0x0, plwindow =
>> 0x0,
>>    auto_path = 0x0, tk_file = 0x0, bufmax = 0, dp = 0, server_nokill = 0,
>>    plbuf_buffer_grow = 0, plbuf_buffer_size = 0, plbuf_buffer = 0x0,
>> plbuf_top = 0,
>>    plbuf_readpos = 0, plbufOwner = 0, difilt = 0, diclpxmi = 0, diclpxma = 0,
>> diclpymi = 0,
>>    diclpyma = 0, dipxmin = 0, dipymin = 0, dipxmax = 0, dipymax = 0, dipxax =
>> 0, dipxb = 0,
>>    dipyay = 0, dipyb = 0, aspdev = 0, aspect = 0, aspori = 0, caspfactor = 0,
>> mar = 0, jx = 0,
>>    jy = 0, didxax = 0, didxb = 0, didyay = 0, didyb = 0, diorot = 0, dioxax =
>> 0, dioxay = 0,
>>    dioxb = 0, dioyax = 0, dioyay = 0, dioyb = 0, dimxax = 0, dimxb = 0, dimyay
>> = 0, dimyb = 0,
>>    dimxmin = 0, dimymin = 0, dimxmax = 0, dimymax = 0, dimxpmm = 0, dimypmm
>> = 0,
>>    page_status = 0, freeaspect = 0, portrait = 0, patt = 0, inclin = {0, 0},
>> delta = {0, 0},
>>    nps = 0, currx = 0, curry = 0, mark = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, space
>> = {0, 0, 0, 0,
>>      0, 0, 0, 0, 0, 0}, nms = 0, timecnt = 0, alarm = 0, pendn = 0, curel = 0,
>> esc = 0 '\000',
>>    scale = 0, chrdef = 0, chrht = 0, symdef = 0, symht = 0, majdef = 0, majht =
>> 0, mindef = 0,
>>    minht = 0, setpre = 0, precis = 0, xdigmax = 0, ydigmax = 0, zdigmax = 0,
>> xdigits = 0,
>>    ydigits = 0, zdigits = 0, timefmt = 0x0, label_func = 0x0, label_data = 0x0,
>> vppxmi = 0,
>>    vppxma = 0, vppymi = 0, vppyma = 0, sppxmi = 0, sppxma = 0, sppymi = 0,
>> sppyma = 0,
>>    clpxmi = 0, clpxma = 0, clpymi = 0, clpyma = 0, phyxmi = 0, phyxma = 0,
>> phyxlen = 0,
>>    phyymi = 0, phyyma = 0, phyylen = 0, umx = 0, umy = 0, xpmm = 0, ypmm = 0,
>> base3x = 0,
>>    base3y = 0, basecx = 0, basecy = 0, domxmi = 0, domxma = 0, domymi = 0,
>> domyma = 0,
>>    zzscl = 0, ranmi = 0, ranma = 0, cxx = 0, cxy = 0, cyx = 0, cyy = 0, cyz =
>> 0, czx = 0,
>>    czy = 0, czz = 0, nplwin = 0, plwin = {{dxmi = 0, dxma = 0, dymi = 0, dyma =
>> 0, wxmi = 0,
>>        wxma = 0, wymi = 0, wyma = 0} <repeats 64 times>}, nsubx = 0, nsuby = 0,
>> cursub = 0,
>>    spdxmi = 0, spdxma = 0, spdymi = 0, spdyma = 0, vpdxmi = 0, vpdxma = 0,
>> vpdymi = 0,
>>    vpdyma = 0, vpwxmi = 0, vpwxma = 0, vpwymi = 0, vpwyma = 0, wpxscl = 0,
>> wpxoff = 0,
>>    wpyscl = 0, wpyoff = 0, wmxscl = 0, wmxoff = 0, wmyscl = 0, wmyoff = 0,
>> wdxscl = 0,
>>    wdxoff = 0, wdyscl = 0, wdyoff = 0, dev_compression = 0, cfont = 0, FT =
>> 0x0,
>>    plPlotterPtr = 0x0, dev_unicode = 0, alt_unicode = 0, fci = 0,
>> dev_hrshsym = 0,
>>    original_chrdef = 0, original_chrht = 0, psdoc = 0x0, qsasconfig = 0x0,
>> dev_gradient = 0,
>>    ngradient = 0, xgradient = 0x0, ygradient = 0x0, n_polygon = 0, x_polygon
>> = 0x0,
>>    y_polygon = 0x0, stream_closed = 0, line_style = 0, dev_mem_alpha = 0,
>>    has_string_length = 0, string_length = 0, get_string_length = 0,
>> dev_eofill = 0,
>>    dev_modeset = 0, if_boxbb = 0, boxbb_xmin = 0, boxbb_xmax = 0, boxbb_ymin
>> = 0,
>>    boxbb_ymax = 0, mf_infile = 0x0, mf_outfile = 0x0}
>>
>>
>> This seems to happen right away:
>>
>> use PDL;
>> use PDL::Config;
>> use PDL::Graphics::PLplot;
>> use Test::More qw(no_plan);
>>
>> # Use xfig driver because it should always be installed.
>> #my $dev = 'png';
>> my $dev = 'xfig';
>>
>> # redirect STDERR to purge silly 'opened *.xfig' messages
>> my ($pl, $x, $y, $min, $max, $oldwin, $nbins);
>>
>> ###
>> # Initial test to work around font file brain damage:  for some kinds of
>> # PLplot errors, control never returns to us.  FMH.
>> #   --CED
>> ###
>>
>> my $tmpdir  = $PDL::Config{TEMPDIR} || "/tmp";
>> my $tmpfile = $tmpdir . "/foo$$.$dev";
>>
>> $pl = PDL::Graphics::PLplot->new (DEV => $dev,
>>                                    FILE => "test2.$dev",
>>                                    BACKGROUND => [255,255,255]);
>>
>>
>> Anything else to look for?
>>
>>
> 


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

[Plplot-devel] Protecting plP_state calls by level checks

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

Hi Phil:

To avoid segfaults when plschr is called before plinit (see
<https://sourceforge.net/p/plplot/bugs/162/>) it is essential to
protect the plP_state( PLSTATE_CHR ); call you introduced into plschr
with a level check.  At the same time (commit id 1424994f) I also
implemented similar level checks to the plP_state( PLSTATE_SYM ); call
you introduced to plssym and the plP_state( PLSTATE_FILL ); call where
you removed the existing level check when you moved that call to the
spat routine.  (I now realize that additional spat level check is
redundant since spat is only called from functions which already do
level checks, but I think it is best to leave it in for code clarity.)

My question for you is did you forget the level check for
the plP_state calls in plschr and plssym by design or
in error?

If by design, then we have to figure out some other way to provide
users with a soft landing (not a segfault) when they call plschr or
plssym before plinit.

If in error, then you should probably review any other plP_state
changes you made during your wxwidgets/plbuf changes to make sure the
plP_state calls are protected by level checks in all cases.

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] Results of the comprehensive test on Cygwin

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> I am actually quite pleased it got as far as it did (to the very last test, i.e., static build,
> traditional install tree) before it failed.
>
> That means the two fixes I made for the Cygwin issues you discovered before (which
> happened much sooner in the comprehensive test) are working properly even though
> one of those fixes was just an educated guess.
>
Quite so - we are moving ahead here.

> It appears from my quick look at this latest Cygwin issue you discovered there is
> trouble for the static case with linking Fortran executables with Fortran, C, and C++
> libraries together for the traditional build of the fortran examples. I will take a look at
> what happens for the CMake build versus the traditional build for fortran examples
> for the static case on Cygwin versus Linux, and that might provide some insight.
> Since this issue is happening for the static case, it is possible if I reorder the libraries
> that are linked, that I can solve this issue. But we will see, and it may take me a few
> days to get back to you with a possible fix.
>
I understand. This type of issues can be really nasty to sort out. Hopefully a comparison of the two cases will bring the cause to light without too much trial and error.

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.

Re: [Plplot-devel] Results of the comprehensive test on Cygwin

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

On 2015-05-18 08:17-0000 Arjen Markus wrote:

> Please find the results of the comprehensive test on Cygwin using
the latest version. It fails in the static build, using the installed
examples, but the other configurations seem fine. So we are making
progress. What is going wrong with the installed examples is, however,
a mystery to me.

Hi Arjen:

I am actually quite pleased it got as far as it did (to the very last
test, i.e., static build, traditional install tree) before it failed.

That means the two fixes I made for the Cygwin issues you discovered
before (which happened much sooner in the comprehensive test) are
working properly even though one of those fixes was just an educated
guess.

It appears from my quick look at this latest Cygwin issue you
discovered there is trouble for the static case with linking Fortran
executables with Fortran, C, and C++ libraries together for the
traditional build of the fortran examples. I will take a look at what
happens for the CMake build versus the traditional build for fortran
examples for the static case on Cygwin versus Linux, and that might
provide some insight. Since this issue is happening for the static
case, it is possible if I reorder the libraries that are linked, that
I can solve this issue. But we will see, and it may take me a few days
to get back to you with a possible fix.

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
__________________________