Hello Hernan, If you have issues installing Alien::proj then could you please file a bug report? https://github.com/shawnlaffan/perl-alien-proj
If you have proj installed with its headers then Alien::proj will run a system install. This will just use your existing installation. If it cannot find the headers then it will run a share install, which means it builds the system from source code. You have not said what operating system you are using but as an example the libproj-dev package is needed on ubuntu to trigger a system install. WRT Ed's comment about GDAL bindings, Geo::GDAL::FFI provides these for perl and has methods to convert rasters to and from PDL ndarrays. https://metacpan.org/pod/Geo::GDAL::FFI https://metacpan.org/pod/Geo::GDAL::FFI::Band#SetPiddle Regards, Shawn. On Tue, 12 Apr 2022 at 04:29, Hernán De Angelis <variablestarli...@gmail.com> wrote: > Hi Ed > > Thank you for your detailed response. > > I understand that Alien::proj will install the latest proj. For some > reason I cannot manage to build it. On the other hand Alien::gdal builds > ok. > > I understand from your answer that PDL will build even if Alien::proj is > not present. I wonder why then I get the error below. What could be missing > here? > > I also understand that PDL has operated this way since 2014 but I have not > had this problem before even when I update PDL every time there is a new > upgrade and have used PDL since 2006. So something is not as it was > recently either in PDL code or my machine. I am trying to discern what it > is. > > I will investigate this a bit more and see what I can find. > > Again a big thank you for taking the pains of maintaining and developing > PDL further. And even answering these emails! That's much appreciated! > > Minor comments: I meant FFT and not FFTW. GLUT just compiled fine, maybe > something got changed since this morning... And please disregard the > "whimsical" part, just a bit of misplaced humor :-) > > > Best regards > > Hernán > > > make[3]: Entering directory > '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Cartography' > chmod 755 ../../blib/arch/auto/PDL/Transform/Transform.so > Manifying 1 pod document > make[3]: Leaving directory > '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Cartography' > make[3]: Entering directory > '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' > "/usr/local/perls/perl-5.34.1/bin/perl" "-I../../../blib/arch" > "-I../../../blib/lib" > "-MPDL::PP=PDL::Transform::Proj4,PDL::Transform::Proj4,Proj4,,1" Proj4.pd > "/usr/local/perls/perl-5.34.1/bin/perl" -MExtUtils::Command::MM -e > 'cp_nonempty' -- Proj4.bs > ../../../blib/arch/auto/PDL/Transform/Proj4/Proj4.bs 644 > /usr/local/perls/perl-5.34.1/bin/perl: symbol lookup error: > ../../../blib/arch/auto/PDL/GIS/Proj/Proj.so: undefined symbol: > proj_list_operations > make[3]: *** [Makefile:863: Proj4.pm] Error 127 > make[3]: Leaving directory > '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' > make[2]: *** [Makefile:516: subdirs] Error 2 > make[2]: Leaving directory '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform' > make[1]: *** [Makefile:515: subdirs] Error 2 > make[1]: Leaving directory '/root/.cpan/build/PDL-2.078-0/Libtmp' > make: *** [Makefile:552: subdirs] Error 2 > > > > > > > > > Den 2022-04-11 kl. 18:12, skrev Ed .: > > Hi Hernán! > > > > PDL’s build (which I suspect you normally do using a tool that doesn’t > show you these messages) is only warning you that it can’t build Proj4 or > HDF4. It will carry on and build everything else that it can, as hopefully > you’re seeing. You’re saying core and GSL work, which wouldn’t be true if > everything else hadn’t built? You say “FFTW”, but there is only an “FFT” in > PDL. https://metacpan.org/pod/PDL::FFTW3 is an external distribution, and > is recommended over PDL::FFT. > > > > The build system was restructured last year so that the tests for those > things now live within their submodule directories. That is the idiomatic > way (in ExtUtils::MakeMaker-using distributions) of doing these things, and > allowed deleting of lots of unnecessary “protection” code, since those > tests aren’t tried if the submodule doesn’t build (which makes sense if you > think about it). > > > > Yes, PDL needs the Alien::* stuff for this. That allows outsourcing of > things like building (or even just finding, which is surprisingly fiddly) a > PROJ installation to other code. If you don’t have the Alien modules > installed, PDL works fine but without the submodules those would have > needed. This has been how PDL has operated (not building submodules that > don’t have needed bits) since at least the year 2014. I don’t understand > your point about “whimsical” or Proj v9, since PDL has supported PROJ v6+ > since version 2.064, over 3 months ago. If you have an OS-packaged PROJ v6 > or newer, then install Alien::proj, which PDL now looks for (note, not > Alien::Proj4), it will see the installed version and not build its own. If > you then reinstall PDL, it will see that and build the > PDL::Transform::Proj4 stuff (the name “Proj4” is unimportant, it’s updated > to v6+ so don’t worry). > > > > There is certainly some demand for PDL GDAL support. The sensible way > would be to make a separate distribution for it. I wouldn’t be surprised if > it only needed similar code to current PDL::GIS::Proj, with the equivalent > of wrapping a forward and backward transform with parameters. If you’d like > to create such a thing, we (the PDL porters) can help! Join the IRC channel > and/or email on here :-) > > > > The Fortran stuff is only warnings. You will note the submodules still > built, passed tests and installed. The Fortran code in those submodules > (Minuit and Slatec) are written in Fortran 77, and are dramatically > obsolete. We may or may not remove them into separate distributions, since > I doubt anyone uses them. Nevertheless, they still work. Minuit 2 (not yet > supported by PDL) is written in C++. Slatec is obsolete and replaced by > LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra. > > > > Please open an issue on https://github.com/Perl-GPU/OpenGL-GLUT/issues > describing the problem you’re having with GLUT to help us fix it. My plan > is to roll OpenGL::GLUT back into a single OpenGL distribution to ease > installation/use. > > > > Best regards, > > Ed > > > > *From: *Hernán De Angelis <variablestarli...@gmail.com> > *Sent: *11 April 2022 09:26 > *To: *pdl-general@lists.sourceforge.net > *Subject: *[Pdl-general] PDL 2.078 > > > > Hi all > > Thanks Ed and others for the great job you do maintaining and developing > PDL. Hats off! > > Today I got news that 2.078 was available so I promptly went on CPAN and > hit upgrade. But for the first time in *many* years PDL did not just build > smoothly right away. > > Upon investigation I see that PDL complains about Proj4 and HDF4 lacking > when trying to build PDL::Transform. Problem is I cannot find anywhere in > perdl.conf where I can tell PDL not to care about this and not run the > t/gis_proj.t and t/proj_transform.t tests. If I remember correctly that > possibility existed years ago. Can we still build PDL without using Proj? > Perhaps using --force? But that is not very elegant ... > > A related question is: does PDL really need Alien::* for this stuff? I > would prefer not to mess with that because these packages install lots of > stuff I do not need nor want in my system. I actually work everyday with > geoinformatics and normally have the latest gdal/ogr and proj. If PDL needs > proj I believe it would be much better to have PDL rely on those rather > than some whimsical Alien::* installing ancient proj4 versions (proj is v. > 9 now). > > Less serious stuff: > - Glut fails to install at the end but this has been the case for many > months and not been a problem > - there are a lot of FORTRAN warnings (see exerpt below), perhaps some > deprecated syntax that the latest gfortran (11.2.1 20220316) does not like. > > Good things: > - Core, FFTW, GSL build smoothly as usual. > > > Best > > Hernán > > > > > # # # # # # > # some fortran warnings > # # # # # # > > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 120 at (1) > slatec/tred2.f:112:72: > > 112 | 180 G = G + Z(J,K) * Z(I,K) > > | 1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 180 at (1) > slatec/tred2.f:118:72: > > 118 | 200 G = G + Z(K,J) * Z(I,K) > > | 1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 200 at (1) > slatec/tred2.f:131:72: > > 131 | DO 260 K = 1, J > > | 1 > Warning: Fortran 2018 deleted feature: Shared DO termination label 260 at > (1) > slatec/tred2.f:149:72: > > 149 | 340 G = G + Z(I,K) * Z(K,J) > > | 1 > Warning: Fortran 2018 deleted feature: DO termination statement which is > not END DO or CONTINUE with label 340 at (1) > slatec/tred2.f:151:72: > > 151 | DO 360 K = 1, L > > | 1 > Warning: Fortran 2018 deleted feature: Shared DO termination label 360 at > (1) > > > > > _______________________________________________ > pdl-general mailing list > pdl-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-general >
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general