[Pdl-porters] plplot 5.9.10 was just released, does PDL::Graphics::PLPlot work?

Discussion:

Chris Marshall

2013-10-06 14:35:26 UTC

I haven't been able to build the latest with cygwin but it
looks promising---just no time on my end. Has anyone
else given it a check?

--Chris

Douglas Hunt

2013-10-06 22:51:09 UTC

Permalink

Hi Chris: I'll try to build this as soon as I can fit it in.

Regards,

Doug

Post by Chris Marshall
I haven't been able to build the latest with cygwin but it
looks promising---just no time on my end. Has anyone
else given it a check?
--Chris
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

s***@optusnet.com.au

2013-10-07 01:27:58 UTC

Permalink

Hi Chris, Doug,

PLplot-5.9.10 builds ok for me on Windows, but there's a problem with
PDL-Graphics-PLplot-0.62 built against 5.9.10:

C:\PDL-Graphics-PLplot-0.62/PLplot.xs:19554: undefined reference to
`_c_plwid'
collect2.exe: error: ld returned 1 exit status
dmake: Error code 129, while making
'blib\arch\auto\PDL\Graphics\PLplot\PLplot.dll'

It's a fairly simple fix - the one and only occurrence of "c_plwid" in
plplot.pd needs to be changed to "c_plwidth" iff building against
plplot-5.9.10.

I don't know where they document this change ... it's not specified in the
changelog, afaics.

That's using PDL-2.006. I'll install the latest 2.007 pre-release in a
perl-5.16.2 and check how it goes with the same P::G::PLplot-0.62 and
plplot-5.9.10.

Because of (what I think is) MinGW bugginess, we can't build a usable
P:G::PLplot as part of the PDL build. So I build it separately after PDL has
been built and installed, using either the source that ships with PDL or the
source that's on CPAN (whichever is the latest).
Last time I checked, it was CPAN that had the latest source, so I've been
building using that source.

I would personally prefer that P::G::PLplot be removed from PDL core - only
because I think that would make P::G::PLplot easier to build and maintain.
(No duplication of source material, and therefore also no "out-of-synch"
issues.)
And one less check that would need to be done every time a new version of
PDL is released.

Cheers,
Rob

-----Original Message-----
From: Chris Marshall
Sent: Monday, October 07, 2013 1:35 AM
To: pdl-porters
Subject: [Pdl-porters] plplot 5.9.10 was just released,does
PDL::Graphics::PLPlot work?

I haven't been able to build the latest with cygwin but it
looks promising---just no time on my end. Has anyone
else given it a check?

--Chris

Craig DeForest

2013-10-07 04:25:53 UTC

Permalink

I would personally prefer that P::G::PLplot be removed from PDL core - only because I think that would make P::G::PLplot easier to build and maintain. (No duplication of source material, and therefore also no "out-of-synch" issues.)
And one less check that would need to be done every time a new version of PDL is released.

Doug Hunt

2013-10-07 15:04:25 UTC

Permalink

Hi Craig, all: I'm happy to keep maintaining the external P::G::PLplot if
you all want to take it out of the core. It can be a hassle having it in
the core anyway, like you say. I personally always work with the external
version because I like to be able to add features quickly without messing
with the PDL core.

Regards,

Doug

***@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611

Post by Craig DeForest

I'm for that too, as part of the general separation of non-core parts. Should that be handled as part of a larger splitting-out task? My sense is that PDL 3.0 is partly about cleaning up the core and partly about cleaning up the module structure...
Cheers,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Chris Marshall

2013-10-07 23:15:09 UTC

Permalink

Hi Doug-

I would like to see the PDL components with major external dependancies
spun off into their own modules. Ideally we would have Alien::PLplot,etc to
make the dependency resolution more robust and seamless.

--Chris

Post by Doug Hunt
Hi Craig, all: I'm happy to keep maintaining the external P::G::PLplot if
you all want to take it out of the core. It can be a hassle having it in
the core anyway, like you say. I personally always work with the external
version because I like to be able to add features quickly without messing
with the PDL core.
Regards,
Doug
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611

Post by Craig DeForest

Post by s***@optusnet.com.au
I would personally prefer that P::G::PLplot be removed from PDL core -
only because I think that would make P::G::PLplot easier to build and
maintain. (No duplication of source material, and therefore also no
"out-of-synch" issues.)
And one less check that would need to be done every time a new version of
PDL is released.

I'm for that too, as part of the general separation of non-core parts.
Should that be handled as part of a larger splitting-out task? My sense is
that PDL 3.0 is partly about cleaning up the core and partly about cleaning
up the module structure...
Cheers,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Craig DeForest

2013-10-08 01:09:47 UTC

Permalink

Cool!

I'd like to see most (all?) of what is now in the core be available as a Bundle::PDL through CPAN, and have PDL itself be pretty much what is now in Core. Doing it that way makes it easy to get a graphics module etc. up but still gives separation so we don't have to update everything all at once.

It would still be nice to impose some sort of numbering regularization across the Bundle, though -- maybe increment everything to the next ten in minor revisions periodically. I'm not sure the best way to do that. Have I missed a discussion about that topic?

Cheers,
Craig

Post by Chris Marshall
Hi Doug-
I would like to see the PDL components with major external dependancies
spun off into their own modules. Ideally we would have Alien::PLplot,etc to
make the dependency resolution more robust and seamless.
--Chris

Post by Craig DeForest

I'm for that too, as part of the general separation of non-core parts.
Should that be handled as part of a larger splitting-out task? My sense is
that PDL 3.0 is partly about cleaning up the core and partly about cleaning
up the module structure...
Cheers,
Craig
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Chris Marshall

2013-10-20 21:50:51 UTC

Permalink

I've successfully built plplot-5.9.10 on cygwin and now I'm
trying to build PDL::Graphics::PLplot from the external CPAN
module. After applying the c_plwid->c_plwidth fix and setting
PLPLOT_LIBDIR and PLPLOT_INCDIR and having the library
search try libplplotd.dll.a I was able to get the Makefile written.

Compiling got a bunch of errors from places where int types
were used for places that now have a different interface: The
add_deletedata_magic now uses size_t rather than int, and
PDL_Indx is the appropriate type for index values.

After the compile finished, the link step failed with the following
errors:

g++-4 -shared -L/home/chm/local/plplot/lib -L/usr/local/lib PLplot.o
-o blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll \
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14.dll
-L/home/chm/local/plplot/lib -lplplotd -lX11 \

PLplot.o: In function `XS_PDL__Graphics__PLplot_plGetCursor':
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59589: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59629: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59629: undefined
reference to `___stack_chk_fail'
PLplot.o: In function `XS_PDL__Graphics__PLplot_plgdev':
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59654: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59669: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59669: undefined
reference to `___stack_chk_fail'
PLplot.o: In function `XS_PDL__Graphics__PLplot_plgfnam':
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59674: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59689: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59689: undefined
reference to `___stack_chk_fail'
PLplot.o: In function `XS_PDL__Graphics__PLplot_plgver':
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59714: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59729: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59729: undefined
reference to `___stack_chk_fail'
collect2: ld returned 1 exit status
Makefile:478: recipe for target
`blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll' failed
make: *** [blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll] Error 1

Still, this is very exciting to be this close to building and using
PDL::Graphics::PLplot. Thoughts about the failed link and whether
or if the underlying plplot library can handle 64bit-sized indexes
for pdls?

Thanks,
Chris

Doug Hunt

2013-10-21 15:12:17 UTC

Permalink

Hi Chris: Thanks much for working on this. I still haven't found the
tuits to look at this--sorry!

A quick google of ___stack_chk_guard led to:

http://wiki.osdev.org/GCC_Stack_Smashing_Protector

This sounds like a gcc symbol. The web page indicates:

'Don't forget to add -fstack-protector-all to the gcc flags.'

This might make your link better.

Best Regards,

Doug

***@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611

Post by Chris Marshall
I've successfully built plplot-5.9.10 on cygwin and now I'm
trying to build PDL::Graphics::PLplot from the external CPAN
module. After applying the c_plwid->c_plwidth fix and setting
PLPLOT_LIBDIR and PLPLOT_INCDIR and having the library
search try libplplotd.dll.a I was able to get the Makefile written.
Compiling got a bunch of errors from places where int types
were used for places that now have a different interface: The
add_deletedata_magic now uses size_t rather than int, and
PDL_Indx is the appropriate type for index values.
After the compile finished, the link step failed with the following
g++-4 -shared -L/home/chm/local/plplot/lib -L/usr/local/lib PLplot.o
-o blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll \
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14.dll
-L/home/chm/local/plplot/lib -lplplotd -lX11 \
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59589: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59629: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59629: undefined
reference to `___stack_chk_fail'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59654: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59669: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59669: undefined
reference to `___stack_chk_fail'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59674: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59689: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59689: undefined
reference to `___stack_chk_fail'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59714: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59729: undefined
reference to `___stack_chk_guard'
/home/chm/pdl/try/PDL-Graphics-PLplot-0.62/PLplot.c:59729: undefined
reference to `___stack_chk_fail'
collect2: ld returned 1 exit status
Makefile:478: recipe for target
`blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll' failed
make: *** [blib/arch/auto/PDL/Graphics/PLplot/PLplot.dll] Error 1
Still, this is very exciting to be this close to building and using
PDL::Graphics::PLplot. Thoughts about the failed link and whether
or if the underlying plplot library can handle 64bit-sized indexes
for pdls?
Thanks,
Chris

s***@optusnet.com.au

2013-10-07 10:37:48 UTC

Permalink

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

Post by s***@optusnet.com.au
It's a fairly simple fix - the one and only occurrence of "c_plwid" in
plplot.pd needs to be changed to "c_plwidth" iff building against
plplot-5.9.10.

It's a bit of a bugger - the 5.9.10 plplot.h still defines "plwid" to
"c_plwid", as well as defining "plwidth" to "c_plwidth". But "c_plwid" never
makes it into the library.
And I don't see any macros defining the plplot version - seems you have to
access the library itself to determine that.

Anyway, this is (I believe) a portable patch to the 0.62 plplot.pd:

####################################
--- plplot.pd_orig 2013-10-07 21:07:10 +1100
+++ plplot.pd 2013-10-07 21:02:34 +1100
@@ -2085,6 +2085,11 @@
#include <plplotP.h>
#include <plevent.h>
#include <stdio.h>
+
+#ifdef plwidth
+#define c_plwid c_plwidth
+#endif
+
EOH

# The create_low_level_constants function is used to make the #define'd
######################################

And the same change needs to be made to the plplot.pd that ships with the
PDL-2.006_91 source. (So I've just now applied that patch to the git
plplot.pd.)

Post by s***@optusnet.com.au
That's using PDL-2.006. I'll install the latest 2.007 pre-release in a
perl-5.16.2 and check how it goes with the same P::G::PLplot-0.62 and
plplot-5.9.10.

I've just checked using PDL-2.006_91 - no additional problems were thrown
up.

Cheers,
Rob