P Kishor wrote: > Starting a new thread. Background -- wanted to create surface plots a > la R (http://addictedtor.free.fr/graphiques/RGraphGallery.php?graph=27) > but with PDL. > > Was unable to install PDL::Graphics::TriD and PDL::Graphics::PLplot > > P::G::T kept on choking up on various issues, and eventually it turns > out that it is now choking up on OpenGL even though OpenGL itself > comes prebuilt and standard on Mac OS X, per opengl.org
The TriD module requires the headers and correct link to build. OSX has an atypical library strategy compared to linux or *BSD. > Tried to install PLplot separately. Failed miserably until Hazen > Babcock suggested that I try installing via cmake but with ENABLE_pdl > OFF. Sometimes what is obvious to someone is completely opaque to > someone else. So, I tried cmake with -DENABLE_PDL=OFF and > -DENABLE_PDL=0 but no cigar until I tried it with -DENABLE_pdl=OFF > (note lower case 'pdl'). This time plplot installation worked and > everything got installed to /usr/local/plplot > It is usually better to test installs to non-system directories since if you put stuff into the main paths that is broken or incomplete other programs may be affected. > So, this time in perldl.conf I turned off WITH_3D and turned on > PLPLOT. However, I still get the following > > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[2]: *** [../../blib/arch/auto/PDL/Graphics/PLplot/PLplot.bundle] > Error 1 > make[1]: *** [subdirs] Error 2 > make: *** [subdirs] Error 2 > punk...@lucknow ~/Projects/PDL-2.4.4_08$ > You don't show which symbols are not found. Are you sure you set the library and include paths to PLplot in perldl.conf? > > This has been most frustrating. I understand that open source software > is a labor of love, and because of the variety of configurations that > it works on, it will always need massaging. I also view PDL has a tool > of great power, but if I, with more than rudimentary knowledge of > computers, is unable to get PDL even started on my computer, it shows > we have a long way to go. I know I can't complain about this if I > don't do something about this. My hope is that with my ministrations > and travails, we can come up with simple and effective complete > installs of PDL just as the R folks have done for their open source > package. > One of the ongoing efforts in PDL development has been increasing robustness and portability so more of the time "things just work". However, that can be tricky when the functionality is provided by a library external to perl. Users willing to put in the effort to sort things out on new platforms are appreciated. Even problem reports help. Willingness to interact with the development team to solve problems is big help. I'm confident that with your continued patience and persistence you'll soon have a PDL working. > Soon as I get everything going successfully, I will definitely write > up a simple, easy to understand instructions document. The current > documentation of plplot, opengl and even PDL is less than easy. > > Thanks to all those who responded. I still have miles to go. > If you don't use the HDF library functionality you should be ok if all of the internal type function tests passed. For the external dependencies like PGPLOT, GSL, FFTW2, PLplot,... the base PDL should still work if the tests pass. BTW, we have seen test failures when you have an older or broken PDL in the @INC path since the tests do not currently check to test only what was built. One of the goals for the TriD refactoring was to make the 3D graphics work on MS Windows and MacOSX systems reliably and easily. We *do* appreciate your work here since that will help to make PDL more accessible to OSX users. Best wishes, Chris P.S. I think you may be closer than you think but I hear and understand the frustration. _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
