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:[email protected]>
*Sent: *11 April 2022 09:26
*To: *[email protected]
*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
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
