[gdal-dev] test failures on pkgsrc build of 3.3.2rc3

Even Rouault 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 
all obviously.
> pkgsrc build log (showing configue output), driver list (from ogrinfo
> failure), and test output at:
>    http://www.lexort.com/GDAL/
> 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 mailing list