plplot-general — PLplot user discussion group

Re: [Plplot-general] Building plplot on Windows 10

[Alan W. I. <Ala...@gm...>]

On 2019-04-14 15:54-0600 Walt Brainerd wrote:

> I am trying again without success to build plplot on Windows.
>
> cmake.exe -DCMAKE_INSTALL_PREFIX=install ../plplot.git >& cmake.out
>
> produces
>
>    Build FAILED.
>
>
> "C:\walt\Software\Plplot\build_dir\CMakeFiles\3.14.2\VCTargetsPath.vcxproj"
> (default target) (1) ->
>
> C:\walt\Software\Plplot\build_dir\CMakeFiles\3.14.2\VCTargetsPath.vcxproj(14,2):
> error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was
> not found. Confirm that the path in the <Import> declaration is correct,
> and that the file exists on disk.
>
> That file (of course?) does not exist in the C directory.
> Help please for someone who does not know much about C++ or cmake.
> I just want to build it to use it with Fortran. I can use Cygwin or MSYS.
> Thanks.

I can't help you with platform specifics since I don't have good access to any
Windows platform other than Wine, and current Wine bugs stop
me from trying out either MinGW-w64/MSYS2 or Cygwin on that platform.

However, I do want to make the comment that in general, PLplot users
have good luck with it on Windows.  This claim is based on the fact
that roughly half our users use various Windows platforms yet from the
lack of complaints (other than yours) they appear to be having success
with PLplot.  Furthermore, Arjen's extensive tests of the Cygwin,
MinGW-w64/MSYS2, and MSVC platforms give good results in general.  So
my guess is whatever the issue is for you, it is likely a small unique
one related to how your platform is configured to build software
rather than any general problem with PLplot on Windows.

Note, we do not support MSYS since the MinGW-w64/MSYS2 project has
long superseded that.  But to help find the source of what appear to
be unique problems in your case please do give extensive details
(e.g., much more than above such as a full CMake cache file, full
cmake output, full build output) for your Cygwin platform.  And also
please try to install MinGW-w64/MSYS2 following the well-documented
steps at <https://github.com/msys2/msys2/wiki> and give us detailed
PLplot configuration and build results for that case as well.

I assume once you give those details on one or both of those
well-tested platforms, other PLplot users here with access to those
platforms should be able to weigh in on what might be specifically
wrong in your case.

Alan
__________________________
Alan W. Irwin

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-general] Building plplot on Windows 10

[Walt B. <wal...@gm...>]

I am trying again without success to build plplot on Windows.

cmake.exe -DCMAKE_INSTALL_PREFIX=install ../plplot.git >& cmake.out

produces

    Build FAILED.


"C:\walt\Software\Plplot\build_dir\CMakeFiles\3.14.2\VCTargetsPath.vcxproj"
(default target) (1) ->

C:\walt\Software\Plplot\build_dir\CMakeFiles\3.14.2\VCTargetsPath.vcxproj(14,2):
error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the <Import> declaration is correct,
and that the file exists on disk.

That file (of course?) does not exist in the C directory.
Help please for someone who does not know much about C++ or cmake.
I just want to build it to use it with Fortran. I can use Cygwin or MSYS.
Thanks.

-- 
Walt Brainerd

Re: [Plplot-general] No specific subroutine for the generic...

[Fernando M. R. da M. <ro...@ro...>]

On Wed, 20 Mar 2019 02:21:28 -0700 (PDT), "Alan W. Irwin"
<Ala...@gm...> wrote:


> On 2019-03-19 22:56-0300 Fernando M. Roxo da Motta wrote:
> 
> > On Tue, 19 Mar 2019 18:10:45 -0700 (PDT), "Alan W. Irwin"
> > <Ala...@gm...> wrote:  
> >> [.... It is] important to use Fortran examples that are consistent
> >> with whatever release you are using for PLplot, and I am pretty
> >> sure from what you posted above that you don't have such Fortran
> >> example consistency right now.  
> >
> >  I suspected that.  That was the reason I stated that I was using an
> > example set of a version prior to the installed version.
> >  
> >>
> >> To solve this, I suggest you build PLplot from the latest release
> >> (PLplot-5.14.0) yourself.  5.14.0 has important bug fixes relative
> >> to 5.13.0 so 5.14.0 is the version we recommend (and the only
> >> version we support).  
> >
> >  I understand that.   I prefer to adhere to the version as
> > contemporary to the installation version I am using.   Makes things
> > easier to administer.   I only use different version if I can get it
> > from a PPA (whatever it means. ;) ).  
> 
> I agree using a system installation prefix for a PLplot build is not a
> good idea.  But avoiding that problem is straightforward.
> All you have to do is specify a unique PLplot
> installation prefix directory that belongs to your user account so you
> can delete that whole installation tree easily without interfering
> with system files.
> 
> For example, here is how I configure, build, test, and install PLplot
> here using my "software" account which I have established for
> developing my software projects.
> 

  Thank you for the tips.  I will give it some thought.  ;)

> 
> For example, on my Debian Testing system, I can look for a specific
> fortran example in packages using the following command:
> 
> irwin@merlin> apt-file search examples/fortran/x00f.f90  
> plplot-doc: /usr/share/doc/plplot-doc/examples/fortran/x00f.f90
> 

  Yes, Ubuntu has this tool as well.   It keeps silence when asked for
the example:

$ apt-file update
Atingido:1 http://linux.teamviewer.com/deb stable InRelease
Ign:2 http://dl.google.com/linux/chrome/deb stable
InRelease Obter:3 http://cran-r.c3sl.ufpr.br/bin/linux/ubuntu
bionic-cran35/ InRelease [3.609 B]
=====8<-------- lots of messages ----------------
Atingido:38 http://ppa.launchpad.net/ys/emojione-picker/ubuntu xenial
InRelease Baixados 3.609 B em 9s (400
B/s) Lendo listas de pacotes... Pronto
Construindo árvore de dependências       
Lendo informação de estado... Pronto
All packages are up to date.
(although the messages are in portuguese, it wnt without errors)

$ sudo apt-file search examples/fortran/x00f.f90  

$

  So, no Fortran examples for Ubuntu.  :(


  Best regards.


  Roxo

-- 
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <ro...@ro...>               | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
                PU5RXO                                  | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Re: [Plplot-general] No specific subroutine for the generic...

[Alan W. I. <Ala...@gm...>]

On 2019-03-20 02:21-0700 Alan W. Irwin wrote:

> # Configure the PLplot build using locally built and installed lua,
> # lasi, qhull, and CMake (each with their own install prefixes).  The
> # -DBUILD_TEST=ON -DUSE_INCRTCL_VERSION_4=ON options are needed so
> # that (i) build-tree testing is enabled and (ii)
> # Tcl/Tk/Itcl/Itk/Iwidgets will be consistently found for Debian
> # Testing.
> # ../plplot.git is the location of the top-level directory of the
> # source tree corresponding to the working directory of a git checkout of the 
> PLplot repository
> # at SourceForge.
> time (env 
> CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5:/home/software/lasi_svn/install:/home/software/qhull/install 
> "/home/software/cmake/install-3.13.2/bin/cmake" 
> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake -DBUILD_TEST=ON 
> -DUSE_INCRTCL_VERSION_4=ON ../plplot.git >& cmake.out)

P.S.  I should have also stated that assuming you don't want to deal
with complications with local installations of lua, lasi, and qhull
and assuming your Ubuntu version provides cmake-3.7.2 or higher (our
minimum acceptable version of CMake for plplot-5.14.0 is 3.7.2, but
for the planned plplot-5.15.0 release that minimum CMake version will
likely be bumped to at least 3.13.2), then the above configuration
step can be simplified to

time(cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake -DBUILD_TEST=ON -DUSE_INCRTCL_VERSION_4=ON ../plplot.git >& cmake.out)

Alan

__________________________
Alan W. Irwin

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-general] No specific subroutine for the generic...

[Alan W. I. <Ala...@gm...>]

On 2019-03-19 22:56-0300 Fernando M. Roxo da Motta wrote:

> On Tue, 19 Mar 2019 18:10:45 -0700 (PDT), "Alan W. Irwin"
> <Ala...@gm...> wrote:
>> [.... It is] important to use Fortran examples that are consistent with whatever
>> release you are using for PLplot, and I am pretty sure from what you
>> posted above that you don't have such Fortran example consistency
>> right now.
>
>  I suspected that.  That was the reason I stated that I was using an
> example set of a version prior to the installed version.
>
>>
>> To solve this, I suggest you build PLplot from the latest release
>> (PLplot-5.14.0) yourself.  5.14.0 has important bug fixes relative to
>> 5.13.0 so 5.14.0 is the version we recommend (and the only version
>> we support).
>
>  I understand that.   I prefer to adhere to the version as
> contemporary to the installation version I am using.   Makes things
> easier to administer.   I only use different version if I can get it
> from a PPA (whatever it means. ;) ).

I agree using a system installation prefix for a PLplot build is not a
good idea.  But avoiding that problem is straightforward.
All you have to do is specify a unique PLplot
installation prefix directory that belongs to your user account so you
can delete that whole installation tree easily without interfering
with system files.

For example, here is how I configure, build, test, and install PLplot here using
my "software" account which I have established for developing
my software projects.

# Create an empty build-tree and install tree
mkdir -p /home/software/plplot/HEAD/build_dir
rm -rf /home/software/plplot/HEAD/build_dir/* ~/plplot/installcmake

# Change directory to that initially empty build-tree.
cd /home/software/plplot/HEAD/build_dir

# Configure the PLplot build using locally built and installed lua,
# lasi, qhull, and CMake (each with their own install prefixes).  The
# -DBUILD_TEST=ON -DUSE_INCRTCL_VERSION_4=ON options are needed so
# that (i) build-tree testing is enabled and (ii)
# Tcl/Tk/Itcl/Itk/Iwidgets will be consistently found for Debian
# Testing.
# ../plplot.git is the location of the top-level directory of the
# source tree corresponding to the working directory of a git checkout of the PLplot repository
# at SourceForge.
time (env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5:/home/software/lasi_svn/install:/home/software/qhull/install "/home/software/cmake/install-3.13.2/bin/cmake" -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake -DBUILD_TEST=ON -DUSE_INCRTCL_VERSION_4=ON ../plplot.git >& cmake.out)

# Build
time make -j16 all >& all.out

# Optional test
time ctest -j16 >& ctest.out

# Install using the /home/software/plplot/installcmake installation prefix
# configured above
time make -j16 install >& install.out

I use the -j16 option above to take full advantage of the 16 hardware
threads of my Ryzen 7 1700 PC, and I also use ccache.  As a result the
*total* time required for the above configure, build, and install steps takes
less than a minute while the optional ctest step takes only 1 minute and 20
seconds (!) on my hardware.

So again, building and installing modern PLplot should be completely straightforward
for you.  However, if you want to stick strictly with Ubuntu binary versions
of PLplot, then that might be OK as well for you because you may have just
not installed the exact package that contains those examples.

For example, on my Debian Testing system, I can look for a specific fortran example
in packages using the following command:

irwin@merlin> apt-file search examples/fortran/x00f.f90
plplot-doc: /usr/share/doc/plplot-doc/examples/fortran/x00f.f90

So to get access to those examples, I would have to install the plplot-doc
package.
Ubuntu should be quite similar since its PLplot packages are derived from
the Debian ones.  So I would be surprised if they actually forgot to
package the Fortran examples, but the name of the package might be a little
different for Ubuntu.
So I suggest you first install the apt-file package
(which contains /usr/bin/apt-file), then as root update that command
using

apt-file update

After that update you should be able to mimic my command above in
an ordinary user account to find the exact Ubuntu package name that
contains the PLplot fortran examples that are consistent with the 
binary version of PLplot that exists on your particular Ubuntu version.

I hope that apt-file idea solves your original question, but even if
that is a success I also hope you also consider building and
installing your own version of PLplot since that is so easy to do and
because of the bug-fixing and support arguments I mentioned earlier.

Alan
__________________________
Alan W. Irwin

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-general] No specific subroutine for the generic...

[Fernando M. R. da M. <ro...@ro...>]

On Tue, 19 Mar 2019 18:10:45 -0700 (PDT), "Alan W. Irwin"
<Ala...@gm...> wrote:

> On 2019-03-19 18:24-0300 Fernando M. Roxo da Motta wrote:
> 
> >
> >
> >  Hi all,
> >
> >
> >  I am trying to build the sample programs in Fortran of PLPLOT.   I
> > am just adapting the Makefile from an older version, as Ubuntu
> > seems to have the Fortran sample programs removed from the
> > distribution.  :/
> >
===================8<----------  Lot of things clipped out ------
> > Error: There is no specific subroutine for the generic
> > ‘plparseopts’ at (1) Makefile:74: recipe for target 'x01f' failed
> > make: *** [x01f] Error 1
> >
> >
> >  Does anyone has an idea about what is going on?  
> 
> Hi Roxo:
> 
> Thanks for your interest in PLplot, and, yes, I am pretty
> sure I know what is going on.
> 
> There have been a number of important backwards-incompatible
> Fortran changes for recent releases of PLplot (see
> README.cumulated_release for the details) and the Fortran examples
> have been changed to reflect that for each release.  Therefore, it is
> important to use Fortran examples that are consistent with whatever
> release you are using for PLplot, and I am pretty sure from what you
> posted above that you don't have such Fortran example consistency
> right now.

  I suspected that.  That was the reason I stated that I was using an
example set of a version prior to the installed version.

> 
> To solve this, I suggest you build PLplot from the latest release
> (PLplot-5.14.0) yourself.  5.14.0 has important bug fixes relative to
> 5.13.0 so 5.14.0 is the version we recommend (and the only version
> we support).

  I understand that.   I prefer to adhere to the version as
contemporary to the installation version I am using.   Makes things
easier to administer.   I only use different version if I can get it
from a PPA (whatever it means. ;) ).


  Once again, thank you for your attention.

> 
> The 5.14.0 tarball will include Fortran examples that are consistent
> with that release.  See our
> [wiki](https://sourceforge.net/p/plplot/wiki/Home/) for how to build  
> and test 5.14.0.  It is one of those deals where it is completely
> straightforward "if you know how".  However, if you have any trouble
> following those instructions, don't hesitate to ask here for further
> help.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> 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
> __________________________
> 







  Roxo

-- 
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <ro...@ro...>               | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
                PU5RXO                                  | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Re: [Plplot-general] No specific subroutine for the generic...

[Alan W. I. <Ala...@gm...>]

On 2019-03-19 18:24-0300 Fernando M. Roxo da Motta wrote:

>
>
>  Hi all,
>
>
>  I am trying to build the sample programs in Fortran of PLPLOT.   I am
> just adapting the Makefile from an older version, as Ubuntu seems to
> have the Fortran sample programs removed from the distribution.  :/
>
>  I am using [Xu|U]buntu 18.04 LTS and Plplot 5.13.
>
>  The problem I am having is during make fase:
>
> $ make
> /usr/bin/gfortran  x00f.f90 -o x00f
> `PKG_CONFIG_PATH="/usr/lib/pkgconfig" pkg-config  --cflags --libs
> plplot-fortran` -lplfortrandemolib x00f.f90:46:37:
>
>     call plparseopts( PL_PARSE_FULL )
>                                     1
> Error: There is no specific subroutine for the generic ‘plparseopts’ at
> (1) Makefile:74: recipe for target 'x00f' failed
> make: *** [x00f] Error 1
>
>  The pkg-config returns:
>
> $ pkg-config  --cflags --libs plplot-fortran
> -I/usr/include/plplot
> -I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot
> -I/usr/include/plplot -lplplotfortran
>
>  Even if I try to compile other samples I get a similar result:
>
> $ make x01f
> /usr/bin/gfortran  x01f.f90 -o x01f
> `PKG_CONFIG_PATH="/usr/lib/pkgconfig" pkg-config  --cflags --libs
> plplot-fortran` -lplfortrandemolib x01f.f90:170:31:
>
>    call plstyl( 1, 1500, 1500 )
>                               1
> Error: There is no specific subroutine for the generic ‘plstyl’ at (1)
> x01f.f90:173:25:
>
>    call plstyl( 0, 0, 0 )
>                         1
> Error: There is no specific subroutine for the generic ‘plstyl’ at (1)
> x01f.f90:34:34:
>
>    call plparseopts(PL_PARSE_FULL)
>                                  1
> Error: There is no specific subroutine for the generic ‘plparseopts’ at
> (1) Makefile:74: recipe for target 'x01f' failed
> make: *** [x01f] Error 1
>
>
>  Does anyone has an idea about what is going on?

Hi Roxo:

Thanks for your interest in PLplot, and, yes, I am pretty
sure I know what is going on.

There have been a number of important backwards-incompatible
Fortran changes for recent releases of PLplot (see
README.cumulated_release for the details) and the Fortran examples
have been changed to reflect that for each release.  Therefore, it is
important to use Fortran examples that are consistent with whatever
release you are using for PLplot, and I am pretty sure from what you
posted above that you don't have such Fortran example consistency right now.

To solve this, I suggest you build PLplot from the latest release
(PLplot-5.14.0) yourself.  5.14.0 has important bug fixes relative to
5.13.0 so 5.14.0 is the version we recommend (and the only version
we support).

The 5.14.0 tarball will include Fortran examples that are consistent
with that release.  See our
[wiki](https://sourceforge.net/p/plplot/wiki/Home/) for how to build
and test 5.14.0.  It is one of those deals where it is completely
straightforward "if you know how".  However, if you have any trouble
following those instructions, don't hesitate to ask here for further
help.

Alan
__________________________
Alan W. Irwin

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-general] No specific subroutine for the generic...

[Fernando M. R. da M. <ro...@ro...>]

  Hi all,


  I am trying to build the sample programs in Fortran of PLPLOT.   I am
just adapting the Makefile from an older version, as Ubuntu seems to
have the Fortran sample programs removed from the distribution.  :/

  I am using [Xu|U]buntu 18.04 LTS and Plplot 5.13.

  The problem I am having is during make fase:

$ make
/usr/bin/gfortran  x00f.f90 -o x00f
`PKG_CONFIG_PATH="/usr/lib/pkgconfig" pkg-config  --cflags --libs
plplot-fortran` -lplfortrandemolib x00f.f90:46:37:

     call plparseopts( PL_PARSE_FULL )
                                     1
Error: There is no specific subroutine for the generic ‘plparseopts’ at
(1) Makefile:74: recipe for target 'x00f' failed
make: *** [x00f] Error 1

  The pkg-config returns:

$ pkg-config  --cflags --libs plplot-fortran
-I/usr/include/plplot
-I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot
-I/usr/include/plplot -lplplotfortran

  Even if I try to compile other samples I get a similar result:

$ make x01f
/usr/bin/gfortran  x01f.f90 -o x01f
`PKG_CONFIG_PATH="/usr/lib/pkgconfig" pkg-config  --cflags --libs
plplot-fortran` -lplfortrandemolib x01f.f90:170:31:

    call plstyl( 1, 1500, 1500 )
                               1
Error: There is no specific subroutine for the generic ‘plstyl’ at (1)
x01f.f90:173:25:

    call plstyl( 0, 0, 0 )
                         1
Error: There is no specific subroutine for the generic ‘plstyl’ at (1)
x01f.f90:34:34:

    call plparseopts(PL_PARSE_FULL)
                                  1
Error: There is no specific subroutine for the generic ‘plparseopts’ at
(1) Makefile:74: recipe for target 'x01f' failed
make: *** [x01f] Error 1


  Does anyone has an idea about what is going on?


  TIA.


  Roxo

-- 
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <ro...@ro...>               | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
                PU5RXO                                  | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Vincent M. <vin...@po...>]

Hi Alan,

I can also today report that gtk-fortran / PLplot is running OK on these 
virtual machines:

- Gentoo 201808 KDE: gfortran 7.3.0, PLplot 5.14 built with CMake,

- Manjaro 18.0.2: gfortran 8.2.1, PLplot 5.14 built with CMake,

- openSUSE 15.0: gfortran 7.3.1, PLplot 5.13.

> It is great that all those different platforms are working.  However, 
> I suggest
> you should build PLplot-5.14.0 (similar to your Sid approach) on each 
> of these
> platforms (including FreeBSD 12.0) to take advantage of the large 
> number of
> PLplot bug fixes that have occurred for that version compared to 
> previous versions.

On FreeBSD 12.0, it was more difficult to build PLplot 5.14 with Fortran 
support because at first CMake did not find gfortran which is named 
gfortran8. Finally I have succeeded using:

$ export FC=/usr/local/bin/gfortran8
$ cmake -D CMAKE_INSTALL_PREFIX=/home/osboxes/myplplot ../plplot-5.14.0

Then gtk-fortran was built successfully using:

$ PKG_CONFIG_PATH=/home/osboxes/myplplot/lib/pkgconfig cmake -D 
CMAKE_Fortran_COMPILER:FILEPATH="/usr/local/bin/gfortran8" ..

All the gtk-fortran PLplot examples run OK in FreeBSD. That's great !

Best regards

Vincent

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Alan W. I. <Ala...@gm...>]

Hi Vincent:

On 2019-03-15 09:55+0100 Vincent MAGNIN wrote:

> Hi Alan,
>
> I have finally successfully build gtk-fortran & PLplot>=5.13, as you can see 
> on this screenshot:
>
> https://github.com/vmagnin/gtk-fortran/blob/gtk3/screenshots/hl_plplot8e_MSYS2_Windows7.png

Nice screenshot, and excellent news!

>
> But I used a workaround. Instead of using find_package(plplot), we use 
> pkg-config, which gives us everything we need to build the whole:

[...]

> It was tested OK in:
>
> * Kubuntu 18.10: gfortran 8.2.0, PLplot 5.13
> * Fedora 29: gfortran 8.3.1, PLplot 5.13
> * MSYS2 / Windows 7: gfortran 8.3.0, PLplot 5.14
> * Ubuntu Sid with the PLplot 5.14 installed using CMake. The command
>   for building gtk-fortran was:
>   |PKG_CONFIG_PATH=/home/osboxes/myplplot/lib/pkgconfig cmake -D
>   CMAKE_BUILD_TYPE=debug -D CMAKE_PREFIX_PATH=/home/osboxes/myplplot ..|
>
> Under FreeBSD 12.0, it does not work because PLplot is 5.12.0, and the PLplot 
> library have been renamed only in the 5.13 version.

It is great that all those different platforms are working.  However, I suggest
you should build PLplot-5.14.0 (similar to your Sid approach) on each of these
platforms (including FreeBSD 12.0) to take advantage of the large number of
PLplot bug fixes that have occurred for that version compared to previous versions.

> I will still work on a purer CMake solution using find_package(plplot). But 
> at the moment, the pkg-config is very satisfying for the user since it works 
> on every tested platform.

It is good that the pkg-config alternative is working well for you.
But that is a legacy approach so it is also good you are still working
on getting our preferred "pure" approach working for you.  And, of
course, if you find any bugs in that preferred approach or anything
you don't understand about it, please let us know.

>
> Note also that two of our PLplot examples give harmless warnings:
>
> |$ ./hl_plplot30e Plplot Fortran Warning: plscmap1la: inconsistent sizes for 
> intensity, coord1, coord2, coord3, alpha, and/or alt_hue_path ||$ 
> ./hl_plplot4e Plplot Fortran Warning: pllegend: inconsistent sizes for the 
> following arrays: opt_array text_colors text ...|
>
> Some of our arrays transmitted to PLplot functions seem to be declared with 
> an incorrect size.

I am glad to hear that these warnings are harmless in your case, i.e.,
our default action (typically using a size corresponding to the
smaller of the arrays) when inconsistent array sizes are specified is
working for you.  But, of course, it is better to fix these issues by
specifying consistently sized arrays.

> Finally, thank you very much, Alan, for the help you gave me.

You are welcome.  And, of course, you testing PLplot on all those different
platforms is a big help to us as well.

Alan
__________________________
Alan W. Irwin

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-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Vincent M. <vin...@po...>]

Hi Alan,

I have finally successfully build gtk-fortran & PLplot>=5.13, as you can 
see on this screenshot:

https://github.com/vmagnin/gtk-fortran/blob/gtk3/screenshots/hl_plplot8e_MSYS2_Windows7.png

But I used a workaround. Instead of using find_package(plplot), we use 
pkg-config, which gives us everything we need to build the whole:

   find_package(PkgConfig REQUIRED)

     pkg_check_modules(PLPLOT-FORTRAN REQUIRED plplot-fortran)
     pkg_check_modules(PLPLOT REQUIRED plplot)

     # Setup CMake to use PLplot, tell the compiler where to look for 
headers
     # and to the linker where to look for libraries:
     include_directories(${PLPLOT-FORTRAN_INCLUDE_DIRS})
     link_directories(${PLPLOT-FORTRAN_LIBRARY_DIRS})
     # Add other flags to the compiler:
     add_definitions(${PLPLOT-FORTRAN_CFLAGS_OTHER})

     set(LIBRARIES ${LIBRARIES} ${PLPLOT_LIBRARIES})
     include_directories(${PLPLOT_INCLUDE_DIRS})
     set(CMAKE_REQUIRED_LIBRARIES "${PLPLOT_LIBRARIES}")
     set(CMAKE_REQUIRED_INCLUDES "${PLPLOT-FORTRAN_INCLUDE_DIRS}")

It was tested OK in:

  * Kubuntu 18.10: gfortran 8.2.0, PLplot 5.13
  * Fedora 29: gfortran 8.3.1, PLplot 5.13
  * MSYS2 / Windows 7: gfortran 8.3.0, PLplot 5.14
  * Ubuntu Sid with the PLplot 5.14 installed using CMake. The command
    for building gtk-fortran was:
    |PKG_CONFIG_PATH=/home/osboxes/myplplot/lib/pkgconfig cmake -D
    CMAKE_BUILD_TYPE=debug -D CMAKE_PREFIX_PATH=/home/osboxes/myplplot ..|

Under FreeBSD 12.0, it does not work because PLplot is 5.12.0, and the 
PLplot library have been renamed only in the 5.13 version.

I will still work on a purer CMake solution using find_package(plplot). 
But at the moment, the pkg-config is very satisfying for the user since 
it works on every tested platform.

Note also that two of our PLplot examples give harmless warnings:

|$ ./hl_plplot30e Plplot Fortran Warning: plscmap1la: inconsistent sizes 
for intensity, coord1, coord2, coord3, alpha, and/or alt_hue_path ||$ ./hl_plplot4e Plplot Fortran Warning: pllegend: inconsistent sizes 
for the following arrays: opt_array text_colors text ...|

Some of our arrays transmitted to PLplot functions seem to be declared 
with an incorrect size.

Finally, thank you very much, Alan, for the help you gave me.

Best regards

Vincent


||

||

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Alan W. I. <Ala...@gm...>]

On 2019-03-04 10:16+0100 Vincent MAGNIN wrote:

> 2) I have downloaded PLplot 5.14.0 from SourceForge, built it and installed 
> it (see attached files):
>
> $ mkdir build_pl && cd build_pl
> $ cmake ../plplot-5.14.0 >& cmake.out
> $ make VERBOSE=1 >& make.out
> $ make VERBOSE=1 install >& make_install.out
> $ sudo make VERBOSE=1 install >& make_install.out

Hi Vincent:

I have now had a chance to evaluate your *.out files for errors and warnings.

There were no errors, and for all files other than cmake.out the warnings
were spurious (due to a long-standing bug in gfortran).

The warning messages in your cmake.out file correspond to the following issues:

Missing fundamental libraries:

You should install both the qhull and shapelib development packages since PLplot interpolation
capability (qhull) and map ability (shapelib) is crippled without them.  You can search for
those packages with, e.g.,

irwin@merlin> apt-cache search qhull |grep dev
libqhull-dev - calculate convex hulls and related structures (development files)

irwin@merlin> apt-cache search shp |grep dev
libghc-psqueues-dev - Pure priority search queues
libshp-dev - Library for reading and writing ESRI Shapefiles - development files

So install libqhull-dev and libshp-dev to address these issues.

Missing device drivers:

Many device drivers are missing, e.g., the qt device driver which
is generally the same quality as our cairo device driver, because
you haven't installed the relevant development packages from Sid.
This is probably fine with you since you do have the Sid packages
installed that allow you to build the cairo device driver that you
are interested in at the moment.

Missing bindings:

Many bindings are missing, e.g., D, Java, Ocaml, Python, etc., because
you haven't installed the appropriate development packages from Debian
Sid.  That is probably fine with you since you do have Sid Fortran
support packages installed, and you appear to be interested just in
Fortran at the moment.

In sum, you definitely should install the libqhull-dev and libshp-dev
packages and you should at least be aware that you have many
additional missing PLplot components that could be addressed by
installing additional Sid development packages if/when you or your
colleagues get interested in those additional language bindings or
device drivers.

Alan
__________________________
Alan W. Irwin

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-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Vincent M. <vin...@po...>]

Hi Alan,

I have made some progress concerning PLplot & gtk-fortran:

Le 04/03/2019 à 22:05, Alan W. Irwin a écrit :
> This is just a comment in passing about the installation prefix you
> have chosen by default here.  Instead, I suggest you specify the cmake
> option -DCMAKE_INSTALL_PREFIX=<whatever install prefix you like>.  The
> prefix you chose instead by default was /usr/local.  That is under
> control by the root account which is why you had to install as root.
> But if you use a unique install prefix under user account control
> instead, you don't have to install as the root account, and removing
> that entire prefix directory again for further installation tries is
> so easy compared to removing all the PLplot bits and pieces in
> /usr/local.

I have reverted my virtual machine to the state before building PLplot 
and built it with a -DCMAKE_INSTALL_PREFIX:

osboxes@osboxes:~$ mkdir build_pl && cd build_pl
osboxes@osboxes:~/build_pl$ cmake -D CMAKE_INSTALL_PREFIX=/home/osboxes/myplplot ../plplot-5.14.0 >& cmake.out
osboxes@osboxes:~/build_pl$ make VERBOSE=1 >& make.out
osboxes@osboxes:~/build_pl$ make VERBOSE=1 install >& make_install.out
osboxes@osboxes:~/build_pl$ cd /home/osboxes/myplplot/share/plplot5.14.0/examples/fortran/
osboxes@osboxes:~/myplplot/share/plplot5.14.0/examples/fortran$ make
osboxes@osboxes:~/myplplot/share/plplot5.14.0/examples/fortran$ ./x08f

> find_package(plplot) (which you use below) just works for me here when
> I use it to build the installed examples that are linked with the
> installed PLplot libraries.  Did you forget to set the environment
> variable CMAKE_PREFIX_PATH to your PLplot prefix (/usr/local for now,
> see above) so that the installed version of PLplot can be found?

First I tried this which had the advantage to give me some interesting 
messages:

osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug ..
-- Compiler: GNU 8.3.0 /usr/bin/f95
-- Build type is: debug
-- Compilation flags: -g -pthread -Wall -pedantic -std=f2008 -Wtabs 
-fcheck=all -fbacktrace -Wno-unused-dummy-argument
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
CMake Warning at CMakeLists.txt:143 (find_package):
By not providing "Findplplot.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "plplot", but
CMake did not find one.

Could not find a package configuration file provided by "plplot" with any
of the following names:

plplotConfig.cmake
plplot-config.cmake

Add the installation prefix of "plplot" to CMAKE_PREFIX_PATH or set
"plplot_DIR" to a directory containing one of the above files. If "plplot"
provides a separate development package or SDK, be sure it has been
installed.

-- PLPLOT not found: PLPLOT integration and examples will not be built
-- Configuring done
-- Generating done
-- Build files have been written to: /home/osboxes/gtk-fortran/build
osboxes@osboxes:~/gtk-fortran/build$

Then I tried, as you suggested:

osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug -D 
CMAKE_PREFIX_PATH=/home/osboxes/myplplot ..
-- Compiler: GNU 8.3.0 /usr/bin/f95
-- Build type is: debug
-- Compilation flags: -g -pthread -Wall -pedantic -std=f2008 -Wtabs 
-fcheck=all -fbacktrace -Wno-unused-dummy-argument
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- PLPLOT not found: PLPLOT integration and examples will not be built
-- Configuring done
-- Generating done
-- Build files have been written to: /home/osboxes/gtk-fortran/build
osboxes@osboxes:~/gtk-fortran/build$

I have also tried without success:

osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug -D 
plplot_DIR=/home/osboxes/myplplot/lib/cmake/plplot ..

After some hard fighting, I have just realized that CMake variables are 
case sensitive (but not CMake commands) ! With PLplot<=5.10 we were 
using in gtk-fortran the PLPLOT_FOUND variable. So I have written that 
piece of code:

   find_package(plplot)

   message(STATUS "PLPLOT_FOUND : ${PLPLOT_FOUND}")
   message(STATUS "PLplot_FOUND : ${PLplot_FOUND}")
   message(STATUS "plplot_FOUND : ${plplot_FOUND}")

if(plplot_FOUND)
     message(STATUS "plplot_LIBRARIES : ${plplot_LIBRARIES}")
     message(STATUS "plplot_INCLUDE_DIR : ${plplot_INCLUDE_DIR}")
     message(STATUS "plplot_MODULE_DIR : ${plplot_MODULE_DIR}")
     message(STATUS "PLPLOT_LIBRARIES : ${PLPLOT_LIBRARIES}")
     message(STATUS "PLPLOT_INCLUDE_DIR : ${PLPLOT_INCLUDE_DIR}")
     message(STATUS "PLPLOT_MODULE_DIR : ${PLPLOT_MODULE_DIR}")
     message(STATUS "PLplot_LIBRARIES : ${PLplot_LIBRARIES}")
     message(STATUS "PLplot_INCLUDE_DIR : ${PLplot_INCLUDE_DIR}")
     message(STATUS "PLplot_MODULE_DIR : ${PLplot_MODULE_DIR}")

Which yields:

osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug -D 
CMAKE_PREFIX_PATH=/home/osboxes/myplplot ..

....

-- PLPLOT_FOUND :
-- PLplot_FOUND :
-- plplot_FOUND : 1
-- plplot_LIBRARIES :
-- plplot_INCLUDE_DIR :
-- plplot_MODULE_DIR :
-- PLPLOT_LIBRARIES :
-- PLPLOT_INCLUDE_DIR :
-- PLPLOT_MODULE_DIR :
-- PLplot_LIBRARIES :
-- PLplot_INCLUDE_DIR : PLplot_INCLUDE_DIR-NOTFOUND
-- PLplot_MODULE_DIR :

....
osboxes@osboxes:~/gtk-fortran/build$

> Once you have found the installed PLplot (see comment above), I am not
> sure the above method will work anymore. 
By now, I obtain the following errors when building our gtk-fortran 
PLplot examples:

[ 95%] Building Fortran object 
plplot/CMakeFiles/hl_plplot30e.dir/hl_plplot30e.f90.o
/home/osboxes/gtk-fortran/plplot/hl_plplot30e.f90:49:6:

    use plplot, PI => PL_PI
       1
Fatal Error: Can't open module file ‘plplot.mod’ for reading at (1): No 
such file or directory
compilation terminated.
Error copying Fortran module "plplot/handlers_ex30.mod". Tried 
"plplot/HANDLERS_EX30.mod" and "plplot/handlers_ex30.mod".
Error copying Fortran module "plplot/plplot_code_ex30.mod".  Tried 
"plplot/PLPLOT_CODE_EX30.mod" and "plplot/plplot_code_ex30.mod".
[ 95%] Linking Fortran executable hl_plplot30e
f95: error: CMakeFiles/hl_plplot30e.dir/hl_plplot30e.f90.o: No such file 
or directory
[ 95%] Built target hl_plplot30e

> Instead, I suggest you
> follow the CMake logic (for the case when CORE_BUILD is false) in
> $PLPLOT_PREFIX/share/plplot5.14.0/examples/CMakeLists.txt (our
> principal CMakeLists.txt file for the installed examples);
> $PLPLOT_PREFIX/share/plplot5.14.0/examples/cmake/modules/plplot_configure.cmake 
>
> (a configured file that contains definitions for many useful CMake
> variables); and primarily
> $PLPLOT_PREFIX/share/plplot5.14.0/examples/fortran/CMakeLists.txt
> (which is used to build our fortran examples that are linked against
> the installed PLplot) to build your Fortran source against PLplot.
>
> Of course, if you have any trouble following the CMake logic in the 
> above 3 files,
> please ask again here.

OK, I will read those files.

Just a question: could it be helpful to copy 
plplot-5.14.0/cmake/FindPLplot.cmake into our gtk-fortran/cmake 
directory ? For the previous PLplot versions, there was a 
FindPlplotF95.cmake file in it.

Thanks for your help,

Vincent

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Alan W. I. <Ala...@gm...>]

Hi Vincent:

It sounds from your remarks below that you are making good progress.  More
below in context.


On 2019-03-04 10:16+0100 Vincent MAGNIN wrote:

> Hi Alan and Ole,
>
> thank you for your answers. Understanding a problem is half the solution.
>
> This is the report of my last efforts:
>
> 1) I have uninstalled and purged from my Debian Sid virtual machine all the 
> PLplot packages:
>
> # apt remove libplplot-dev plplot-doc plplot-tcl-dev octave-plplot 
> python3-plplot-qt
> # apt autoremove
> # apt purge libplplot-dev plplot-doc plplot-tcl-dev octave-plplot 
> python3-plplot-qt libplplot-lua libplplot-ocaml plplot-tcl plplot-tcl-bin
>
> 2) I have downloaded PLplot 5.14.0 from SourceForge, built it and installed 
> it (see attached files):
>
> $ mkdir build_pl && cd build_pl
> $ cmake ../plplot-5.14.0 >& cmake.out
> $ make VERBOSE=1 >& make.out
> $ make VERBOSE=1 install >& make_install.out
> $ sudo make VERBOSE=1 install >& make_install.out

This is just a comment in passing about the installation prefix you
have chosen by default here.  Instead, I suggest you specify the cmake
option -DCMAKE_INSTALL_PREFIX=<whatever install prefix you like>.  The
prefix you chose instead by default was /usr/local.  That is under
control by the root account which is why you had to install as root.
But if you use a unique install prefix under user account control
instead, you don't have to install as the root account, and removing
that entire prefix directory again for further installation tries is
so easy compared to removing all the PLplot bits and pieces in
/usr/local.

>
> 3) I have built the Fortran examples and tested successfully some of them:
>
> $ cd /usr/local/share/plplot5.14.0/examples/fortran/
> $ sudo make
> $ ./x08f
>
> Plotting Options:
> < 1> xwin       X-Window (Xlib)
> < 8> xcairo     Cairo X Windows Driver
>
> The examples work fine (I don't know why this time I have no problem 
> concerning the X server).

Excellent!


>
> 4) But now when I build the gtk-fortran project (gtk2devel branch), CMake 
> does not find anymore PLplot:
>
> osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug ..
> -- The Fortran compiler identification is GNU 8.3.0
> -- Check for working Fortran compiler: /usr/bin/f95
> -- Check for working Fortran compiler: /usr/bin/f95  -- works
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Checking whether /usr/bin/f95 supports Fortran 90
> -- Checking whether /usr/bin/f95 supports Fortran 90 -- yes
> -- Compiler: GNU 8.3.0 /usr/bin/f95
> -- Build type is: debug
> -- Compilation flags: -g -pthread -Wall -pedantic -std=f2008 -Wtabs 
> -fcheck=all -fbacktrace -Wno-unused-dummy-argument
> -- Found GTK2_GTK: /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so
> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
> -- PLPLOT not found: PLPLOT integration and examples will not be built
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/osboxes/gtk-fortran/build

find_package(plplot) (which you use below) just works for me here when
I use it to build the installed examples that are linked with the
installed PLplot libraries.  Did you forget to set the environment
variable CMAKE_PREFIX_PATH to your PLplot prefix (/usr/local for now,
see above) so that the installed version of PLplot can be found?

>
> This is the part of the main CMakeLists.txt where we are looking for PLplot:
>
> # PLplot
> if (NOT EXCLUDE_PLPLOT)
> #  find_package(PlplotF95 QUIET)
>   find_package(plplot)
>   set(HAVE_LIBPLPLOTF95D ${PLPLOT_FOUND})
>   if(PLPLOT_FOUND)
>     set(LIBRARIES ${LIBRARIES} ${PLPLOT_LIBRARIES})
>     include_directories(${PLPLOT_INCLUDE_DIR})
>     include_directories(${PLPLOT_MODULE_DIR})
>     set(CMAKE_REQUIRED_LIBRARIES "${PLPLOT_LIBRARIES}")
>     set(CMAKE_REQUIRED_INCLUDES "${PLPLOT_INCLUDE_DIR}; 
> ${PLPLOT_MODULE_DIR}")
>     check_fortran_source_compiles("
>  program tw
>  use plplot
>  implicit none
>
>  real(kind=plflt) :: w = 0.5_plflt
>  call plinit()
>  call plwidth(w)
>  end program tw" NEW_PLPLOT
>     )
>     check_fortran_source_compiles("
>  program tdef
>  use plplot
>  implicit none
>
>  integer :: i = PLESC_DEVINIT
>  end program tdef" NEW_PLPLOT_DEFS
>     )
>   else(PLPLOT_FOUND)
>     message(STATUS "PLPLOT not found: PLPLOT integration and examples will 
> not be built")
>   endif(PLPLOT_FOUND)
> else(NOT EXCLUDE_PLPLOT)
>   message(STATUS "PLPLOT Excluded as command option")
> endif(NOT EXCLUDE_PLPLOT)

Once you have found the installed PLplot (see comment above), I am not
sure the above method will work anymore.  Instead, I suggest you
follow the CMake logic (for the case when CORE_BUILD is false) in
$PLPLOT_PREFIX/share/plplot5.14.0/examples/CMakeLists.txt (our
principal CMakeLists.txt file for the installed examples);
$PLPLOT_PREFIX/share/plplot5.14.0/examples/cmake/modules/plplot_configure.cmake
(a configured file that contains definitions for many useful CMake
variables); and primarily
$PLPLOT_PREFIX/share/plplot5.14.0/examples/fortran/CMakeLists.txt
(which is used to build our fortran examples that are linked against
the installed PLplot) to build your Fortran source against PLplot.

Of course, if you have any trouble following the CMake logic in the above 3 files,
please ask again here.

Alan
__________________________
Alan W. Irwin

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-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Vincent M. <vin...@po...>]

Hi Alan and Ole,

thank you for your answers. Understanding a problem is half the solution.

This is the report of my last efforts:

1) I have uninstalled and purged from my Debian Sid virtual machine all 
the PLplot packages:

# apt remove libplplot-dev plplot-doc plplot-tcl-dev octave-plplot python3-plplot-qt
# apt autoremove
# apt purge libplplot-dev plplot-doc plplot-tcl-dev octave-plplot python3-plplot-qt libplplot-lua libplplot-ocaml plplot-tcl plplot-tcl-bin

2) I have downloaded PLplot 5.14.0 from SourceForge, built it and 
installed it (see attached files):

$ mkdir build_pl && cd build_pl
$ cmake ../plplot-5.14.0 >& cmake.out
$ make VERBOSE=1 >& make.out
$ make VERBOSE=1 install >& make_install.out
$ sudo make VERBOSE=1 install >& make_install.out

3) I have built the Fortran examples and tested successfully some of them:

$ cd /usr/local/share/plplot5.14.0/examples/fortran/
$ sudo make
$ ./x08f

Plotting Options:
  < 1> xwin       X-Window (Xlib)
  < 8> xcairo     Cairo X Windows Driver

The examples work fine (I don't know why this time I have no problem 
concerning the X server).

4) But now when I build the gtk-fortran project (gtk2devel branch), 
CMake does not find anymore PLplot:

osboxes@osboxes:~/gtk-fortran/build$ cmake -D CMAKE_BUILD_TYPE=debug ..
-- The Fortran compiler identification is GNU 8.3.0
-- Check for working Fortran compiler: /usr/bin/f95
-- Check for working Fortran compiler: /usr/bin/f95  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/f95 supports Fortran 90
-- Checking whether /usr/bin/f95 supports Fortran 90 -- yes
-- Compiler: GNU 8.3.0 /usr/bin/f95
-- Build type is: debug
-- Compilation flags: -g -pthread -Wall -pedantic -std=f2008 -Wtabs -fcheck=all -fbacktrace -Wno-unused-dummy-argument
-- Found GTK2_GTK: /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- PLPLOT not found: PLPLOT integration and examples will not be built
-- Configuring done
-- Generating done
-- Build files have been written to: /home/osboxes/gtk-fortran/build

This is the part of the main CMakeLists.txt where we are looking for PLplot:

# PLplot
if (NOT EXCLUDE_PLPLOT)
#  find_package(PlplotF95 QUIET)
   find_package(plplot)
   set(HAVE_LIBPLPLOTF95D ${PLPLOT_FOUND})
   if(PLPLOT_FOUND)
     set(LIBRARIES ${LIBRARIES} ${PLPLOT_LIBRARIES})
     include_directories(${PLPLOT_INCLUDE_DIR})
     include_directories(${PLPLOT_MODULE_DIR})
     set(CMAKE_REQUIRED_LIBRARIES "${PLPLOT_LIBRARIES}")
     set(CMAKE_REQUIRED_INCLUDES "${PLPLOT_INCLUDE_DIR}; ${PLPLOT_MODULE_DIR}")
     check_fortran_source_compiles("
  program tw
  use plplot
  implicit none

  real(kind=plflt) :: w = 0.5_plflt
  call plinit()
  call plwidth(w)
  end program tw" NEW_PLPLOT
     )
     check_fortran_source_compiles("
  program tdef
  use plplot
  implicit none

  integer :: i = PLESC_DEVINIT
  end program tdef" NEW_PLPLOT_DEFS
     )
   else(PLPLOT_FOUND)
     message(STATUS "PLPLOT not found: PLPLOT integration and examples will not be built")
   endif(PLPLOT_FOUND)
else(NOT EXCLUDE_PLPLOT)
   message(STATUS "PLPLOT Excluded as command option")
endif(NOT EXCLUDE_PLPLOT)

Best regards

Vincent

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing... (fwd)

[Alan W. I. <Ala...@gm...>]

__________________________
Alan W. Irwin

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
__________________________

---------- Forwarded message ----------
Date: Wed, 27 Feb 2019 15:34:21 +0100
From: Ole Streicher <ol...@de...>
To: Alan W. Irwin <Ala...@gm...>
Subject: Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran
     interfacing...

Hi Alan, Vincent,

(Alan, please Cc to Vincent, and/or to the list)

On 27.02.19 02:37, Alan W. Irwin wrote:
> On 2019-02-26 14:54+0100 Vincent MAGNIN wrote:
>
>> I have tried some examples and successfully created output files using:
>>
>> < 3> ps         PostScript File (monochrome)
>> <11> svg        Scalable Vector Graphics (SVG 1.1)
>>
>> But for an unknown reason failed to plot anything directly on screen
>> (xwin, tk, qt drivers...) although plplot-driver-qt,
>> plplot-driver-wxwidgets and plplot-driver-xwin are installed. With
>> that kind of message (x33c):
>>
>> Enter device number or keyword: 1
>>
>> *** PLPLOT ERROR, IMMEDIATE EXIT ***
>> Can't open display
>> Program aborted
>

This is probably not connected to plplot. You need to have X11 running
and accessible by the client. So, depending how your setup of the
virtual machine is:

* if you do it directly in the VM window, make sure that you are in an
X11 environment of the VM

* if you login via ssh, use the "-X" option, check the DISPLAY variable
(`echo $DISPLAY`), and try to open a simple other program (like xterm or
so).


> With regard to the Debian Sid package for PLplot, Ole Streicher is the
> maintainer for that.  From my last contact with him my understanding
> is he is still working on getting the installed PLplot examples
> package to work just as well as they do for upstream.  The issue is
> that Debian packaging renames some components of PLplot so the example
> builds need to compensate for that.  I have CC'd Ole to give him a
> chance to summarize on list here where he is in that effort.


The problem for Python is, that the Debian python3-plplot package
includes the packages for all supported Python 3 versions, which
requires that the names shall not conflict. Therefore, they are renamend
in a consistent manner. Usually this is not important, since the
interface for Python 3 is the calling from, and this continues to work.
However, the plplot cmake logic does a number of extra consistency
checks that shoot one in the foot here. And it is not so trivial to
remove those checks (which are not needed for the Debian package, since
the installation already ensures that everything is on place).

Best regards


Ole

Re: [Plplot-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Alan W. I. <Ala...@gm...>]

On 2019-02-26 14:54+0100 Vincent MAGNIN wrote:

> Hi Alan,
>
> this is a report of my progress toward interfacing gtk-fortran and PLplot 
> 5.14:
>
> 1) I finally installed in a virtual machine a Debian Sid (unstable) because 
> if offers the PLplot 5.14 packages.
>
> 2) I have installed the following packages for gtk-fortran and PLplot:
>
> # apt install git gitk cmake gfortran libgtk2.0-dev libgtk-3-dev 
> libplplot-dev plplot-doc
>
> I have successfully built the PLplot examples:
>
> # cd /usr/share/doc/plplot-doc/examples/
> # make
> # ./x00c
>
> I have tried some examples and successfully created output files using:
>
> < 3> ps         PostScript File (monochrome)
> <11> svg        Scalable Vector Graphics (SVG 1.1)
>
> But for an unknown reason failed to plot anything directly on screen (xwin, 
> tk, qt drivers...) although plplot-driver-qt, plplot-driver-wxwidgets and 
> plplot-driver-xwin are installed. With that kind of message (x33c):
>
> Enter device number or keyword: 1
>
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Can't open display
> Program aborted

Hi Vincent:

"Can't open display" normally means you need an X server to be working.

With regard to the Debian Sid package for PLplot, Ole Streicher is the
maintainer for that.  From my last contact with him my understanding
is he is still working on getting the installed PLplot examples
package to work just as well as they do for upstream.  The issue is
that Debian packaging renames some components of PLplot so the example
builds need to compensate for that.  I have CC'd Ole to give him a
chance to summarize on list here where he is in that effort.

But for now, I suggest you simply build Plplot yourself using the
upstream version.  That works essentially perfectly for Debian Testing
= Buster (my platform), and so it should not be that different for
Debian Unstable = Sid.

> 3) On the gtk-fortran side,**when trying to build the project, CMake found 
> PLplot but stopped me with errors like:
>
> CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:175 
> (message):
>  The imported target "PLPLOT::tclmatrix" references the file
>
> "/usr/lib/x86_64-linux-gnu/libtclmatrix.so.10.3.0"
>
>  but this file does not exist.  Possible reasons include:
> ...
>
> Using apt-file, I saw that it was in the plplot-tcl package so I installed 
> plplot-tcl-dev. Then I was similarly obliged to install octave-plplot.
>
> But I am now stopped by this error:
>
> CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:175 
> (message):
>  The imported target "PLPLOT::plplot_pyqt5" references the file
>
>     "/usr/lib/python3/dist-packages/plplot_pyqt5.so"
>
>  but this file does not exist.  Possible reasons include:
>
> ...
>
> I have installed the python3-plplot-qt package:
>
> root@osboxes:~# apt-file search plplot_pyqt5
> python3-plplot-qt: 
> /usr/lib/python3/dist-packages/plplot_pyqt5.cpython-37m-x86_64-linux-gnu.so
> root@osboxes:~# apt install python3-plplot-qt
>
> But CMake still gives me the same error because in that package the file is 
> named plplot_pyqt5.cpython-37m-x86_64-linux-gnu.so instead of 
> plplot_pyqt5.so.

Yes, that is an example of the Debian renaming that is going on in
the packaged version.

> Can you tell me what you think about that problem ? (is it a PLplot problem, 
> a CMake problem, a Debian problem, a gtk-fortran problem ?)

It's a Debian packaging issue that is currently being worked on by Ole
(with some essential upstream help from me that is not completely done
yet) with the goal that Debian installed examples will build and run
without issues for both our CMake-based build system for the installed
examples as well as our traditional Makefile and pkg-config build
system for our installed examples.  (Which would mean the same for
your own apps.) But we aren't there yet (because of years of Debian
packaging neglect until Ole took over).

To avoid such Debian downstream packaging issues for now, you should
simply uninstall *all* Debian packages for PLplot, and instead build
and install upstream PLplot from scratch with your own unique
installation prefix for all PLplot components.  If you have any
trouble with such builds please let me know on-list here since I have
a lot of successful experience with such builds for my Debian Buster
platform.  (I do such builds and extensive run-time tests of those
almost daily to test my git commits before I push them.)

Alan
__________________________
Alan W. Irwin

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-general] Working on PLplot 5.14 and gtk-fortran interfacing...

[Vincent M. <vin...@po...>]

Hi Alan,

this is a report of my progress toward interfacing gtk-fortran and 
PLplot 5.14:

1) I finally installed in a virtual machine a Debian Sid (unstable) 
because if offers the PLplot 5.14 packages.

2) I have installed the following packages for gtk-fortran and PLplot:

# apt install git gitk cmake gfortran libgtk2.0-dev libgtk-3-dev 
libplplot-dev plplot-doc

I have successfully built the PLplot examples:

# cd /usr/share/doc/plplot-doc/examples/
# make
# ./x00c

I have tried some examples and successfully created output files using:

< 3> ps         PostScript File (monochrome)
<11> svg        Scalable Vector Graphics (SVG 1.1)

But for an unknown reason failed to plot anything directly on screen 
(xwin, tk, qt drivers...) although plplot-driver-qt, 
plplot-driver-wxwidgets and plplot-driver-xwin are installed. With that 
kind of message (x33c):

Enter device number or keyword: 1

*** PLPLOT ERROR, IMMEDIATE EXIT ***
Can't open display
Program aborted

3) On the gtk-fortran side,**when trying to build the project, CMake 
found PLplot but stopped me with errors like:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:175 (message):
   The imported target "PLPLOT::tclmatrix" references the file

  "/usr/lib/x86_64-linux-gnu/libtclmatrix.so.10.3.0"

   but this file does not exist.  Possible reasons include:
...

Using apt-file, I saw that it was in the plplot-tcl package so I 
installed plplot-tcl-dev. Then I was similarly obliged to install 
octave-plplot.

But I am now stopped by this error:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:175 (message):
   The imported target "PLPLOT::plplot_pyqt5" references the file

      "/usr/lib/python3/dist-packages/plplot_pyqt5.so"

   but this file does not exist.  Possible reasons include:

...

I have installed the python3-plplot-qt package:

root@osboxes:~# apt-file search plplot_pyqt5
python3-plplot-qt: /usr/lib/python3/dist-packages/plplot_pyqt5.cpython-37m-x86_64-linux-gnu.so
root@osboxes:~# apt install python3-plplot-qt

But CMake still gives me the same error because in that package the file 
is named plplot_pyqt5.cpython-37m-x86_64-linux-gnu.so instead of 
plplot_pyqt5.so.

Note that in my previous email, I reported similar things under Kubuntu 
18.10 with PLplot 5.13, except that I was stopped by another file: 
PLplot needed the file _Pltk_init.so (python-plplot package) which is 
named _Pltk_init.x86_64-linux-gnu.so in Kubuntu 18.10.


Can you tell me what you think about that problem ? (is it a PLplot 
problem, a CMake problem, a Debian problem, a gtk-fortran problem ?)

Cheers

Vincent


-- 

*Vincent MAGNIN*
Maître de conférences
IEMN Laboratoire Central, UMR CNRS 8520
Département Micro-Nano-Opto
Equipe optoélectronique

vin...@un... <mailto:pre...@un...> *|* 
www.univ-lille.fr <http://www.univ-lille.fr>
Avenue Poincaré, bureau 349
BP 60069
59652 Villeneuve d'Ascq Cedex
T.+33 (0)3 20 19 79 67

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Alan W. I. <Ala...@gm...>]

On 2019-01-04 12:39-0800 Alan W. Irwin wrote:

> On 2019-01-04 03:42-0800 Alan W. Irwin wrote:
>
> [...]
>> I notice at <http://repo.msys2.org/mingw/x86_64/> that pango
>> 1.42.[1-4] have already been packaged along with 1.43.0.  So I plan to
>> submit a bug report to the MinGW-w64/MSYS2 maintainers asking them to
>> rebuild 1.42.4 with their present compiler version and drop their
>> packaging effort for 1.43.x because of this bug we have been
>> discussing and also the general instability reason you stated.
>
> Done.  See <https://github.com/Alexpux/MINGW-packages/issues/4830>.
>
> My last bug report to the MinGW-w64/MSYS2 developers got addressed
> late last year with a fix that was rolled out in a timely way.  So
> this project appears to be responsive to bug reports (as opposed to
> ignoring them like some projects do) so I hope to hear soon from them
> whether they decide to go along with this suggestion or not.

Well, it wasn't super quick, but the MinGW-w64/MSYS2 developers
claimed they solved this issue today, see
<https://github.com/Alexpux/MINGW-packages/issues/4830> and a link
from there to another bug report.

Anyhow, this would be a good opportunity for all three of you (Arjen,
Günter, and Tom) to drop Tom's "Requires: gobject-2.0" workaround to
see if this MinGW-w64/MSYS2 bug is really fixed.

Alan
__________________________
Alan W. Irwin

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-general] findwxwidgets.cmake module

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

Hi Alan
I half thought that we had scrapped our findwxWidgets.cmake module,
but I just found that this isn't actually the case.

I've just disabled our version by renaming it, and I've found that the
CMake version does appear to work on Windows. This is using cmake
3.13.3 (the latest release as of writing this email).

I seem to remember that it was for windows builds that we were
maintaining our own version. Perhaps this can now be removed?

Phil

Re: [Plplot-general] dll export of some functions in plstream.h

[Alan W. I. <Ala...@gm...>]

On 2019-01-15 11:47-0000 Phil Rosenberg wrote:

> Hi All
> I've just made a commit exporting a couple of functions into the
> plplotcxx dll and import lib (I'm building on Windows, commit
> 223dff54af4cd13d12c50b26ceb8f8aa67dc6f84). This change fixes a linker
> error I was getting.
>
> I'm only just really starting to make use of dlls and import libs
> rather than just using static libs, so if anyone wishes to check out
> the changes and tell me I've done something incorrectly then feel free
> to let me know and I can look at changing things again.

Hi Phil:

I was curious why we didn't spot these visibility issues with
Coord_Xform_evaluator and Contourable_Data_evaluator before with our
comprehensive testing (which tests both shared and static builds of
our libraries and much more).  That oversight turns out to be due to
these functions not being called anywhere in our examples or bindings.
But it appears your own software has use for these functions so thanks
for addressing this visibility issue for them.

By the way, there may be additional visibility issues for our C++ API
that satisfy the same criteria as these functions, namely (i) they are
useful to libplplotcxx users, but (ii) not currently called anywhere
in our examples or bindings.

Alan
__________________________
Alan W. Irwin

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-general] dll export of some functions in plstream.h

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

Hi All
I've just made a commit exporting a couple of functions into the
plplotcxx dll and import lib (I'm building on Windows, commit
223dff54af4cd13d12c50b26ceb8f8aa67dc6f84). This change fixes a linker
error I was getting.

I'm only just really starting to make use of dlls and import libs
rather than just using static libs, so if anyone wishes to check out
the changes and tell me I've done something incorrectly then feel free
to let me know and I can look at changing things again.

Phil

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Alan W. I. <Ala...@gm...>]

On 2019-01-04 03:42-0800 Alan W. Irwin wrote:

[...]
> I notice at <http://repo.msys2.org/mingw/x86_64/> that pango
> 1.42.[1-4] have already been packaged along with 1.43.0.  So I plan to
> submit a bug report to the MinGW-w64/MSYS2 maintainers asking them to
> rebuild 1.42.4 with their present compiler version and drop their
> packaging effort for 1.43.x because of this bug we have been
> discussing and also the general instability reason you stated.

Done.  See <https://github.com/Alexpux/MINGW-packages/issues/4830>.

My last bug report to the MinGW-w64/MSYS2 developers got addressed
late last year with a fix that was rolled out in a timely way.  So
this project appears to be responsive to bug reports (as opposed to
ignoring them like some projects do) so I hope to hear soon from them
whether they decide to go along with this suggestion or not.

Alan
__________________________
Alan W. Irwin

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-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Alan W. I. <Ala...@gm...>]

On 2019-01-04 15:26+0530 Tom Schoonjans wrote:

> You’re welcome.
>
> The issue here is that pango should never have been updated to 1.43.0 in MSYS2 since it’s an unstable development release, as are all GNOME releases with an odd minor version number. Linux distributions and macOS package managers would never have packaged this release.

Hi Tom:

I confirm your analysis on Debian Testing where there is absolutely no attempt to package 1.43.0
despite the "rolling" nature of that release.

So it appears this issue doesn't have the widespread impact I anticipated.

I notice at <http://repo.msys2.org/mingw/x86_64/> that pango
1.42.[1-4] have already been packaged along with 1.43.0.  So I plan to
submit a bug report to the MinGW-w64/MSYS2 maintainers asking them to
rebuild 1.42.4 with their present compiler version and drop their
packaging effort for 1.43.x because of this bug we have been
discussing and also the general instability reason you stated.

Alan

__________________________
Alan W. Irwin

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-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Tom S. <tom...@me...>]

You’re welcome.

The issue here is that pango should never have been updated to 1.43.0 in MSYS2 since it’s an unstable development release, as are all GNOME releases with an odd minor version number. Linux distributions and macOS package managers would never have packaged this release.

Best,

Tom

> On 4 Jan 2019, at 13:30, Alan W. Irwin <Ala...@gm...> wrote:
> 
> On 2019-01-04 11:47+0530 Tom Schoonjans wrote:
> 
>> Hi all,
>> 
>> 
>> I ran into the same problem a couple of weeks ago. It is in fact a bug in pango 1.43.0 which uses meson as buildsystem instead of autotools, and the pkg-config issue was introduced in the transition.
>> 
>> I reported this as a bug <https://gitlab.gnome.org/GNOME/pango/merge_requests/22#note_390137> and submitted a patch <https://gitlab.gnome.org/GNOME/pango/merge_requests/38>, which is now in master and should end up in 1.44 (or possibly in 1.43.1 if this ever gets released).
>> 
>> In the meantime, the problem can be fixed by executing:
>> 
>> 	echo "Requires: gobject-2.0" >> /mingw64/lib/pkgconfig/pango.pc
>> 
>> followed by building plplot… The cairo backend should build fine then.
>> 
> 
> Thanks, Tom, for that really helpful comment about what appears to be a
> widespread issue with pango 1.43.0.  That's a heavily used free
> library.  So let's hope the upstream pango developers quickly release
> 1.43.1 with your fix and that quickly propagates to free software
> distributions for Linux (thousands of them), Mac OS X (fink, macports,
> and homebrew), and Windows (Cygwin and MinGW-w64/MSYS2).
> 
> @Günter:
> 
> So to summarize, it looks like my recent tests on Debian Testing have
> been fine because I have installed cairo 1.42.3, and that platform has
> not (yet) got around to packaging cairo-1.43.0.  Arjen's test was also
> a success because he has cairo 1.42.1 currently installed (and has not
> yet updated his system), but your recent test failed because you did
> do such an update which exposed you to the bad pango 1.43.0 version.
> So hopefully Tom's above echo command will sort out the issue for you
> until upstream developers fix the issue, and that fix propagates to
> MinGW-w64/MSYS2.
> 
> At the same time, I also stand by my advice to drop "MinGW Makefiles"
> and mingw32-make and use the "Unix Makefiles" or "MSYS Makefiles"
> generators and bash and make instead simply because if you ever run
> into PLplot trouble with the platform, the very much enhanced test
> capability (via bash scripts) you have access to with the latter
> method can be quite useful, e.g., the report tarball that can
> be generated for that case makes it much easier to
> understand your bug reports.
> 
> @Arjen: you will likely also be affected by the same bug and have to do the same fix
> when you update your own MinGW-w64/MSYS2.
> 
> And I will likely be affected by the same bug if Debian Testing starts packaging
> pango 1.43.0.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> 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
> __________________________