[Plplot-general] Can't build/instal cairo driver with 5.11.1 WinXP64, GCC/gfortran 5.3.0

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

Hi "DrO":

I am switching this conversation from support request ticket 38 to the
plplot-general list since that is our favoured method of answering
support requests, and it appears there are a number of issues we still
need to discuss.

On 2016-04-03 16:07-0000 DrO wrote:

> Cheers for that.
>
> 1) Yes, I suppose the ticket [38] can be closed, but with slight reluctance.
>
> As noted earlier, in a "perfect world" the solution would be a fix or
> something in the PLPlot makefiles that allows the MSys side to find the
> extra driver bits.  If you send me some clues as to where/how the PLPlot
> make etc bits look for the extra driver bits, perhaps I can have a go at
> that.
>
> It is almost surely some "simple" path/env thing, but I am not sufficiently
> good at bash/make/config to determine the specifics on my own.  In any case,
> one needs to get to the point where MSys/cmake produces:
>
> ENABLE_DYNDRIVERS:      ON
> DRIVERS_LIST: cairo;mem;null;ps;svg;wingcc;xfig
> DEVICES_LIST:
> memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;mem;n
> ull;ps;svg;wingcc;xfig
>
> instead of
>
> ENABLE_DYNDRIVERS:      ON
> DRIVERS_LIST: mem;null;ps;svg;xfig
> DEVICES_LIST: mem;null;ps;svg;xfig

OK.  It sounds like you still have issues that needs to be addressed
so I will keep the support request ticket 38 open for now although all
further conversation should please occur on the plplot-general mailing
list.

One issue is wingcc is missing.  That is quite unusual (since wingcc
only depends on fundamental Windows libraries that should easily be
found by cmake).

When you reply to this message on the plplot-general mailing list
please include as a separate attachment the compressed captured output
from the cmake command for an initially empty build tree.  Under bash
I would created that compressed file as follows:

mkdir build_tree
cd build_tree
cmake -DCMAKE_INSTALL_PREFIX=whatever wherever_top_of_plplot_source_tree >& cmake.out
gzip cmake.out

The resulting cmake.out.gz should include most of what I need to know to
discover why the fundamental Windows libraries used by wingcc are not
being found.

A completely separate issue is the missing cairo device driver.
However, that is due to the fundamental issue with the "vanilla"
MinGW/MSYS platform I alluded to earlier, namely, unlike
MinGW-w64/MSYS2 the MinGW/MSYS platform is completely missing many
fundamental open-source libraries that give PLplot its power.  In this
case, the pango and cairo libraries and all their many library
dependencies that are required by the cairo device driver are missing,
but the cmake.out.gz file you will be sending me will also have
zillions of WARNING messages about many other open source libraries
that are not found on MinGW/MSYS which is why the result is missing so
much PLplot functionality (the cairo device driver and much more, but
this does not explain the wingcc issue noted above since that device
driver only depends on fundamental Windows system libraries).

One "solution" for the cairo device driver issue is to download the
GTK+ set of libraries for Windows (which includes the required pango
and cairo libraries and their dependencies).  That method sometimes
works, but you inevitably run into ABI trouble with that method
whenever the MinGW compiler that you are using has a different ABI
than the compiler used to build the binary version of GTK+ that you
have downloaded.

> The MinGW installation here is not the bog standard classical MinGW, it is
> one that  follows the much more useful structure based on the excellent work
> found on this site (http://ingar.satgnu.net/devenv/mingw32/base.html), which
> I refer to as the "Ingar MinGW".

I have not heard of this variation of MinGW/MSYS before, but it uses
the same MinGW-w64 runtime as MinGW-w64/MSYS2 and following links at
that site I also found
<http://ingar.satgnu.net/devenv/mingw32/base.html#install_opt> which
shows that the "Ingar MinGW" platform provides GTK+ that is compiled
with the same "Ingar MinGW" compiler and therefore immune to the ABI
troubles I mentioned above for vanilla MinGW/MSYS.  So it appears the
"Ingar MinGW" platform is just like MinGW-w64/MSYS2 in this regard,
but the latter platform provides many additional open-source libraries
that give PLplot its power.

So if you let me know the location of the dll's of all those "Ingar
MinGW" GTK+ libraries, then I should be able to help you to figure
out how to give the PLplot build system a hint concerning finding
them.

For example, one issue with PLplot and many other open-source software
packages is you should not have spaces in the source tree, build tree,
or install tree paths.  So if you have installed your "Ingar MinGW"
platform with a path prefix that includes a space, that would cause
all sorts of find trouble.

Note, however, that once you have addressed both the wingcc and
cairo device driver issues, you still have an extraordinarly weak
version of PLplot.  Which is why I keep mentioning the MinGW-w64/MSYS2
platform which (when it works) gives you a powerful version of PLplot
with almost complete functionality.

With regard to the MinGW-w64/MSYS2 platform I acknowledge all the
terrible troubles with older versions of it that you have reported to
me previously in this conversation, and I can see why as a result you
are so reluctant to use it. So for now, let's concentrate on getting
you up and running with the weak version of PLplot that is possible on
"Ingar MinGW".

However, with regard to the present reliability of MinGW-w64/MSYS2,
Greg Jung, has recently reported complete success with PLplot on that
platform. And one of our core developers, Arjen, has had initial
success with a limited test on that platform last week.  But due to
unfamiliarity with that platform, he violated the complex update rules
relevant at the time when attempting to install more MinGW-w64/MSYS2
packages, and got stuck because of that.  He soon plans to reinstall
MinGW-w64/MSYS2 and follow the much simplified update rules that are
available now with this latest version (see
<https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>).

So in sum we are still quite inexperienced with this platform, and we
will keep in mind the bad results you have had for earlier versions of
this platform, but we soon might be in position to say both a PLplot
user and core PLplot developer have had complete success with a
powerful version of PLplot on the MinGW-w64/MSYS2 platform by
religiously following the installation and upgrade rules for that
platform detailed in
<https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>. Note in
particular the advice there which is "MUST use folder names that
consist of only ascii characters and no spaces" which jibes with my
similar advice above concerning PLplot itself.

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
__________________________