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> 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
*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
