[gdal-dev] test failures on pkgsrc build of 3.3.2rc3
even.rouault at spatialys.com
Wed Sep 1 09:46:16 PDT 2021
> and now have a test run that shows:
> = 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s (0:12:26) =
> which seems quite good overall.
For a reasonably well setup environment, you should not get more than a
handful of failures. 312 definitely indicates something wrong. Looking a
bit at the logs you provide, they are explicit and implicit complaints
about GDAL_DATA not being set. I'm not sure if you're running agains an
installed GDAL lib (in which case, there's something wrong in your build
if it can't find /usr/share/gdal/ or whatever similar dir in which GDAL
data is installed), or if it a in-build GDAL (in which case GDAL_DATA
env var must be explicitly set as done in setdevenv.sh)
A number of PROJ related failures can be caused by some grids being
missing. The 'conus' grid from
http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz (there might be
others from that package. at least this is the one used for our CI) must
in particular be installed in /usr/share/proj (or 'us_noaa_conus.tif' in
PROJ 7 or later)
> Note that this my gdal was built with proj 6.3.2, partly old to avoid a
> version with removed interfaces that other software needs, and partly
> because I haven't gotten to dealing (in packaging) with the new proj
> data layout. As I understand it, though, that's a supported version for
> gdal, and the gdal build succeeds. I suspect if this does matter, it's
> only for a few tests.
It is possible to get a few PROJ related failures from time to time
given which version you use. Our CI covers a number of versions, but not
> pkgsrc build log (showing configue output), driver list (from ogrinfo
> failure), and test output at:
> Looking into the avc failure, I find
> $ ogrinfo ogr/data/avc/testavc/testavc/
> INFO: Open of `ogr/data/avc/testavc/testavc/'
> using driver `AVCBin' successful.
> 1: ARC (Line String)
> 2: LAB (Point)
> But if I leave off the trailing / I get a failure to find a driver. A
> trailing slash on a directrory name seems odd to me, and usually the
> result of completion.
Hum, I suspect you might hit a similar issue as the one for FreeBSD in
where fopen("/some/dir", "rb") succeeds.
Can you test changing that with whatever define is appropriate to test
for your OS and submit the resulting patch ?
My software is free, but my time generally not.
More information about the gdal-dev