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> 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> 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
_______________________________________________
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general
