On 9/3/2010 11:44 AM, Stefan Evert wrote: > Hi Chris! > > Sorry, I don't seem to be explaining myself clearly. > >> No, PDL::Graphics::PGPLOT is always installed. >> To get the "PGPLOT driver" you will need to install >> the Perl PGPLOT module *and* the pgplot library. > > When I wrote "PGPLOT driver", I meant the PDL::Graphics::PGPLOT module, which > I conceptualise as one of the graphics "drivers" of PDL -- I realise this is > rather inaccurate terminology. > >>>> The install should probably make a fuss if the >>>> external package is not installed at time of build
PGPLOT is not a required dependency for PDL. If you look in DEPENDENCIES you'll see that it will build ok without either the PGPLOT module or the underlying pgplot library. >> That would be the PGPLOT module install since >> PDL::Graphics::PGPLOT relies on that. It is more >> of a convenience feature that the PDL::Graphics::PGPLOT >> is installed regardless since if you decide you >> need that, you only need install PGPLOT+pgplot and >> not do a full PDL reinstall. > > Agreed, but it should at least throw a reasonably big warning (or, in an > automatic CPAN install, ask the user whether to install the required PGPLOT > module as well). It could definitely be documented better. Since we're working on the general problem of getting external dependencies sorted out with Alien::XXX modules so a cpan install of PDL will work out of the box on all supported platforms the problem should be resolved more generally then. > BTW, is there a way to get a summary of configuration choices when > Makefile.PL has run? With several screenfuls of output, it's very easy to > miss whether a particular optional module will build or not. The PDL::Config module defines the %PDL::Config hash which is set with the final results of and perldl.conf decisions made by the Makefile.PL process. >>> Except the automatic install with "cpan" doesn't >>> work on Mac OS X, because Makefile.PL fails to >>> locate my MacPorts-installed version of PGPLOT. >>> :-( But a manual install works fine and the PDL >>> demos now run without problems. >> >> If you have the PGPLOT module installed, in a >> non-standard location then you'll need to add >> that to the PERL5LIB environment variable so that >> it can be found. > > It's not the PGPLOT module, but rather the PGPLOT package needed for building > the PGPLOT module. > >> If you mean the PGPLOT module Makefile.PL doesn't >> handle custom locations easily, > > If you build manually, it's easy enough to pass the correct paths to > Makefile.PL, and then PGPLOT builds without problems and passes its tests. > The PGPLOT libs were also easy to install using MacPorts. PLplot is the one > that's giving me a lot of trouble ... > >> I suggest putting >> effort into getting PLplot working instead as we >> would like to move to that as the standard >> dependency for 2D plotting in PDL. > > Well, then let's start troubleshooting PLplot, shall we? Thanks for the report. I'm sure it will be of use for folks doing PLplot development. From the point of view of an Alien::PLplot module and Mac OS X platforms would be a builds-out-of-the-box of PLplot from source on Macs or a similarly available binary package (or both). --Chris > I'm on Mac OS X 10.6 and have installed a Universal build of PLplot 5.9.6 > with the help of MacPorts. Here are my experiences trying to build the > PLplot backend in PDL (checked out from Git): > > 1) Makefile.PL fails to pick up the PLplot installation in /opt/local, with a > rather confusing error message (it can find the library, but not the plplot.h > header). The reason turns out to be that the standard locations hard-coded > in Makefile.PL include "/opt/local/lib" and "/opt/local/include", but not > "/opt/local/include/plplot" (which I would assume is the standard location > for plplot.h). After adding this line to Makefile.PL, PDL is configured to > build the PLplot backend. > > 2) During "make", linking the XS code into a .bundle (shared library) fails > with > >> LD_RUN_PATH="/opt/local/lib" gcc-4.2 -mmacosx-version-min=10.6 -shared >> -L/opt/local/lib -L/usr/local/lib PLplot.o -o >> ../../blib/arch/auto/PDL/Graphics/PLplot/PLplot.bundle \ >> -L/opt/local/lib -lplplotd -lX11 \ >> >> Undefined symbols: >> "_Perl_sv_free", referenced from: >> _pdl_pladv_redodims in PLplot.o >> _pdl_plarrows_redodims in PLplot.o >> _pdl_plaxes_redodims in PLplot.o >> _pdl_plbin_redodims in PLplot.o >> _pdl_plbox_redodims in PLplot.o >> _pdl_plbox3_redodims in PLplot.o >> _pdl_plcol0_redodims in PLplot.o >> _pdl_plcol1_redodims in PLplot.o >> _pdl_plcpstrm_redodims in PLplot.o >> ... > > followed by more than 10,000 lines of similar error messages. The apparent > reason is that Makefile.PL (or something else in the build process, which I > don't understand well enough to guess) messes with the command-line flags > that Perl normally uses to link such shared libraries. If I run the command > > gcc-4.2 -mmacosx-version-min=10.6 -arch x86_64 -arch i386 -arch ppc > -bundle -undefined dynamic_lookup -L/opt/local/lib -L/usr/local/lib PLplot.o > -o ../../blib/arch/auto/PDL/Graphics/PLplot/PLplot.bundle -L/opt/local/lib > -lplplotd -lX11 > > the library compiles fine. > > Unfortunately, I don't know MakeMaker well enough to patch Makefile.PL; and I > don't understand while all these messy hard-coded choices are in there in the > first place. > > 3) In "make test", the PLplot tests segfault on shaded plots, in particular > the following lines in t/plplot.t: > > l. 288ff >> plshades($z, -1, 1, -1, 1, >> $clevel, $fill_width, >> $cont_color, $cont_width, 1, >> 0, \&pltr1, $grid); >> > > l. 298 >> $pl->shadeplot ($z, $nsteps, BOX => [-1, 1, -1, 1], PALETTE => 'RAINBOW'); >> > > If I comment out these lines, the tests pass (and the test script doesn't > realise the commands didn't run). > > A backtrace with gdb suggests that the error happens somewhere deep inside > the PLplot library: > >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0x00000000014be6c0 >> 0x000000010119cabc in pltr1 () >> (gdb) backtrace >> #0 0x000000010119cabc in pltr1 () >> #1 0x00000001011bddc7 in plshade_int () >> #2 0x00000001011be763 in plfshade1 () >> #3 0x00000001011bea6f in plfshades () >> #4 0x00000001011bed53 in c_plshades () >> #5 0x000000010155f45c in pdl_plshades_readdata (__tr=0x1014bfbb0) at >> PLplot.xs:25542 >> #6 0x00000001001a319f in pdl__ensure_trans (trans=0x1014bfbb0, what=<value >> temporarily unavailable, due to optimizations>) at pdlapi.c:1287 >> #7 0x00000001001a3cbb in pdl_make_trans_mutual (trans=0x1014bfbb0) at >> pdlapi.c:899 >> #8 0x00000001015d181e in XS_PDL_plshades (my_perl=0x1014bfbb0, >> cv=0x100b32760) at PLplot.xs:40895 >> #9 0x0000000100075708 in Perl_pp_entersub () >> #10 0x000000010006e6cc in Perl_runops_standard () >> #11 0x000000010006e43a in perl_run () >> #12 0x0000000100000da4 in ?? () >> #13 0x0000000100000cb8 in ?? () > > Perhaps someone knows enough about PLplot to debug this? Is there some > application I could use to test the PLplot library itself in order to find > out whether it's a bug in PLplot (or the MacPorts build) itself, or whether > PDL is to blame? > > Best, > Stefan > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3111 - Release Date: 09/03/10 > 02:34:00 > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
