[Pdl-porters] plplot-5.9.11 and PDL bindings now build on cygwin

[Chris Marshall]

It looks like we're on the way to adding PLplot back
as one of the cross-platform supported graphics
options for PDL users.

--Chris


---------- Forwarded message ----------
From: Chris Marshall <***@gmail.com>
Date: Tue, Dec 31, 2013 at 2:26 PM
Subject: Re: [Plplot-devel] The stable 5.10.0 release cycle starts...
To: PLplot development list <Plplot-***@lists.sourceforge.net>
Cc: Doug Hunt <***@ucar.edu>


Congratulations on the 5.9.11 release!

For the first time I have been able to build the PLplot
library on cygwin and then the perl/PDL bindings. There
were a number of problems along the way but I will follow
up with more specifics separately (what is the preferred
method of communication?)..

I have yet to attempt the build for mingw and strawberry perl
but will let you know of any issues there. Sorry I was not able
to give this feedback before the release window closed with
the holidays and all.

Cheers,
Chris


On Sun, Dec 22, 2013 at 7:41 PM, Alan W. Irwin

The 5.9.11 release process is finished. (Ironically, that coincided
almost perfectly with when the University of Victoria finally fixed my
incoming mail issues!)
The svn commit freeze that was in effect is now thawed, and I look
forward to your commits for our next release (5.10.0) of PLplot which
will be our first stable release since 5.8.0 was released 6 (!) years
ago.
...snip...

[Doug Hunt]

Hi Chris: I'd be interested in what you had to do to get this to build.
I put out a hasty update to PDL::Graphics::PLplot a few weeks ago, but
that was before the 5.9.11 release.

Thanks,

Doug

***@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. [phone]

Post by Chris Marshall
It looks like we're on the way to adding PLplot back
as one of the cross-platform supported graphics
options for PDL users.
--Chris
---------- Forwarded message ----------
Date: Tue, Dec 31, 2013 at 2:26 PM
Subject: Re: [Plplot-devel] The stable 5.10.0 release cycle starts...
Congratulations on the 5.9.11 release!
For the first time I have been able to build the PLplot
library on cygwin and then the perl/PDL bindings. There
were a number of problems along the way but I will follow
up with more specifics separately (what is the preferred
method of communication?)..
I have yet to attempt the build for mingw and strawberry perl
but will let you know of any issues there. Sorry I was not able
to give this feedback before the release window closed with
the holidays and all.
Cheers,
Chris
On Sun, Dec 22, 2013 at 7:41 PM, Alan W. Irwin

The 5.9.11 release process is finished. (Ironically, that coincided
almost perfectly with when the University of Victoria finally fixed my
incoming mail issues!)
The svn commit freeze that was in effect is now thawed, and I look
forward to your commits for our next release (5.10.0) of PLplot which
will be our first stable release since 5.8.0 was released 6 (!) years
ago.
...snip...

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall

Post by Chris Marshall
I have yet to attempt the build for mingw and strawberry perl
but will let you know of any issues there.

For my mingw-built perls, 5.9.11 seems pretty good for
PDL-Graphics-PLplot-0.67 - though not *quite* as good as 5.9.10.

Whereas all t/plplot_library_tests.t passed with 5.9.10, tests 127 and 128
failed with 5.9.11 .... but only with my 64-bit builds of perl.
No problems at all with the 32-bit builds of perl, except for 5.10.0 which
also failed two tests (can't recall which ones ... come to think about it,
they could also have been tests 127 and 128) in t/plplot_library_tests.t.

I'll try to get to the bottom of these failures, despite that they don't
worry me greatly. Anyone have any ideas on what might have changed ?

Chris, as for building the plplot library itself for native Windows, I don't
think there's a cmake option for creating makefiles suitable for any flavour
of make other than 'mingw32-make' - and Strawberry provides only 'dmake'.
You could try grabbing the make utility from:
http://gnuwin32.sourceforge.net/packages.html

FAIK, it's the same (or near enough) as 'mingw32-make'.

Or maybe, you've already got past that problem.

Anyway, if you decide that you need to give 'mingw32-make' a go, but have
trouble locating it, let me know and I'll see if I can dig one up.
I use the same (32-bit) mingw32-make for both 64-bit and 32-bit builds.

Cheers,
Rob

[Chris Marshall]

-----Original Message----- From: Chris Marshall

Post by Chris Marshall
I have yet to attempt the build for mingw and strawberry perl
but will let you know of any issues there.

For my mingw-built perls, 5.9.11 seems pretty good for
PDL-Graphics-PLplot-0.67 - though not *quite* as good as 5.9.10.
Whereas all t/plplot_library_tests.t passed with 5.9.10, tests 127 and 128
failed with 5.9.11 .... but only with my 64-bit builds of perl.

This may be related to the new 64bit index support or
some assumption in the PDL::Graphics::PLplot distribution.
Now that I can actually build these, I should be able to help
debug these as well.

No problems at all with the 32-bit builds of perl, except for 5.10.0 which
also failed two tests (can't recall which ones ... come to think about it,
they could also have been tests 127 and 128) in t/plplot_library_tests.t.
I'll try to get to the bottom of these failures, despite that they don't
worry me greatly. Anyone have any ideas on what might have changed ?
Chris, as for building the plplot library itself for native Windows, I don't
think there's a cmake option for creating makefiles suitable for any flavour
of make other than 'mingw32-make' - and Strawberry provides only 'dmake'.

I just checked and dmake is supposed to be a make(1) compatible
build tool with enhancements so a standard unix makefile output
should work for dmake. Strawberry perl also has gmake distributed
with it as well so that is available as well. In general, I would like
the build requirements to be as minimal as possible so users don't
have to first install "something else I don't know" before they can work
with PDL. :-)

http://gnuwin32.sourceforge.net/packages.html
FAIK, it's the same (or near enough) as 'mingw32-make'.
Or maybe, you've already got past that problem.
Anyway, if you decide that you need to give 'mingw32-make' a go, but have
trouble locating it, let me know and I'll see if I can dig one up.
I use the same (32-bit) mingw32-make for both 64-bit and 32-bit builds.

Will do and thanks for the tips. I'm actually more concerned about
the MSVC builds since I can't test that and ASperl uses that. Are
you able to build for MSVC toolset with the latest plplot-5.9.11?

Have a happy new year,
Chris

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall
Sent: Thursday, January 02, 2014 3:22 AM
To: Sisyphus
Cc: pdl-porters
Subject: Re: [Pdl-porters] plplot-5.9.11 and PDL bindings now build on
cygwin

Post by Chris Marshall

Post by s***@optusnet.com.au
Whereas all t/plplot_library_tests.t passed with 5.9.10, tests 127 and 128
failed with 5.9.11 .... but only with my 64-bit builds of perl.

This may be related to the new 64bit index support or
some assumption in the PDL::Graphics::PLplot distribution.

When I was using plplot-5.9.10, all tests passed.
And I was also forgetting that these failures occur only when I build
against a dynamic 5.9.11 library. When I build against a static 5.9.11
library all tests pass.
In addition to that, the 32-bit "int64" builds of perl pass all of their
tests.

Rebuilding (using the same build script), and I didn't get any failures for
5.10.0. And this second time round, my 64-bit perl-5.16.0 passed all tests,
with the only failures occurring for 64-bit 5.12.0, 5.14.0 and 5.18.0.
Maybe that's the same as I got first time round; I can't be sure .... but
it's all a bit odd.

The problem files (ie the ones that are not as expected) are x22p.svg.2 and
x22p.svg.3. They both display fine, and x22p.svg.1 and x22p.svg.4 are both
as the test script expects.
Anyway - this will give me something to do tonight.

Post by Chris Marshall
In general, I would like
the build requirements to be as minimal as possible so users don't
have to first install "something else I don't know" before they can work
with PDL. :-)

Yes, and once you have the native win32 plplot library installed Strawberry
will provide you with everything you need.
I'm just wondering about the requirements to build the plplot library in the
first place.
I'm fairly sure you'll need cmake, which doesn't ship with Strawberry. After
running the 'cmake...'[1] command you'll then need a suitable 'make' utility
to run the generated makefiles. I've just given it a try and 'dmake' is
*not* suitable, but 'gmake' *is* .... so you shouldn't have too much drama
there, after all :-)

Cheers,
Rob

[1]
cmake -G "MinGW
Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=C:/MinGW/msys/1.0/local
-DBUILD_SHARED_LIBS=OFF -DENABLE_f77=OFF -DENABLE_cxx=OFF -DENABLE_f95=OFF
-DBUILD_TEST=ON ..

[s***@optusnet.com.au]

-----Original Message-----

Post by s***@optusnet.com.au
The problem files (ie the ones that are not as expected) are x22p.svg.2
and x22p.svg.3. They both display fine, and x22p.svg.1 and x22p.svg.4 are
both as the test script expects.
Anyway - this will give me something to do tonight.

It was just a local plplot dll version skew with perls 5.12.0, 5.14.0 and
5.18.0 that was causing the problem. (No such version skew where 5.16.0 was
concerned.)

When building the x22c.svg files, an older plplot dll (probably 5.9.10) was
being used, whereas perl was using the current 5.9.11.

The final result was that both perl and C built identical files (x22c.svg.4
and x22p.svg.4). However, along the way, the older plplot and 5.9.11 did
things a little differently - which resulted in discrepancies in the
intermediate files, and hence the error reports for x22c.svg.2/x22p.svg.2
and x22c.svg.3/x22p.svg.3.
Apparently, the x22 test was the only one thus affected by the version skew.

Cheers,
Rob

This is exactly why I like to avoid building against dynamic libraries.

[Chris Marshall]

Maybe we should add a version check to the perl dll load
that barfs if the dll id is not correct.

--Chris

Post by s***@optusnet.com.au

Post by s***@optusnet.com.au
The problem files (ie the ones that are not as expected) are x22p.svg.2
and x22p.svg.3. They both display fine, and x22p.svg.1 and x22p.svg.4 are
both as the test script expects.
Anyway - this will give me something to do tonight.

It was just a local plplot dll version skew with perls 5.12.0, 5.14.0 and
5.18.0 that was causing the problem. (No such version skew where 5.16.0 was
concerned.)
When building the x22c.svg files, an older plplot dll (probably 5.9.10) was
being used, whereas perl was using the current 5.9.11.
The final result was that both perl and C built identical files (x22c.svg.4
and x22p.svg.4). However, along the way, the older plplot and 5.9.11 did
things a little differently - which resulted in discrepancies in the
intermediate files, and hence the error reports for x22c.svg.2/x22p.svg.2
and x22c.svg.3/x22p.svg.3.
Apparently, the x22 test was the only one thus affected by the version skew.
Cheers,
Rob
This is exactly why I like to avoid building against dynamic libraries.