Hi Hernán, Great to hear your local issue is sorted – thank you to you and Shawn!
PDL absolutely will build without Alien::proj. Problems will only arise if it is installed but broken. You can prove this by making a new Perl installation (“perlbrew” is my recommended tool) with no Alien::proj (but with other actual needed deps like File::Map) then install PDL on it. This is also tested on every single commit of PDL which gets built and tested in our continuous integration (CI) in (among many, many other environments) a container on CentOS with minimal deps. perldl.conf as a mechanism is not a suitable vehicle for this, nor really for anything else. The whole Alien concept in Perl was originally invented to solve this class of problems, for PDL. We are sticking with it until a convincing case is made for something better. Best regards, Ed From: Hernán De Angelis<mailto:variablestarli...@gmail.com> Sent: 12 April 2022 12:50 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.078 Dear all, Just to report that thanks to a good collaboration with Shawn we were able to track the problem to an empty "PKG_CONFIG_PATH" in my system. After adding the proper paths now Alien::proj and PDL both compile fast, well and smoothly. It also seems that PDL will not build without Alien::proj. Then the question remains: would it be possible or desirable to be able to build PDL without proj by giving an appropriate flag in perldl.conf? Best regards and thanks to all Hernán Den 2022-04-12 kl. 11:12, skrev Shawn Laffan: It would be useful to be able to build PDL without the proj-dependent components. This could maybe be done using an environment variable, or an argument passed to the ```perl Makefile.PL``` call. Ed would be better placed to comment on this aspect. Alien::proj will not attempt to build from source if it can find existing libs. If it is building from source on a system where proj>6 is installed then there might be an issue with the probes. The probe to find existing installations uses pkg-config. If that is not on your system, or the proj.pc file is not in the PKG_CONFIG_PATH, then Alien::proj will fall back to a source install. (Note - Hernán is following that up separately). Shawn. On Tue, 12 Apr 2022 at 18:06, Hernán De Angelis <variablestarli...@gmail.com<mailto:variablestarli...@gmail.com>> wrote: Hello Shawn Thanks for your answer. I am not trying to build Alien::proj. I just would like to tell PDL not to care about it. How is it that up to 2.027 this wasn't a problem but it suddenly is in 2.028? I will dig a bit on this and try to find out. I have a dislike of Alien::* since it will install and build things I already have and which I have control over. This may be purely subjective but if I can avoid having this it would be nice. Again, this wasn't a problem before. Why now? I am not asking anyone to work to find it, my question is rather if someone knows of an easy way to bypass having to install Alien::* just to get PDL going, albeit without the functionality provided by proj. I use openSUSE Tumbleweed (rolling release). I have used Linux exclusively since 2005, mostly openSUSE and its predecessors. For the tools I use more often I do not use a package manager (zypper in openSUSE) but I build them (proj, geos, gdal, GRASS GIS, QGIS and others) from source myself. All of them live in /usr/local and subdirectories, properly exported to the path and library path (they actually found each other, no problems there). I normally update Perl modules using CPAN, including PDL, but when troubleshooting is needed I also build from source using the "perl Makefile.pl" method. And yes, I am familiar with Geo::GDAL::FFI. I use it in a couple of projects. It installs and runs fine. Best regards Hernán Den 2022-04-11 kl. 23:57, skrev Shawn Laffan: 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<mailto: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<mailto:variablestarli...@gmail.com> Sent: 11 April 2022 09:26 To: pdl-general@lists.sourceforge.net<mailto: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<mailto:pdl-general@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/pdl-general _______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net<mailto: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
