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

[Even Rouault]

> 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 
https://github.com/OSGeo/gdal/blob/a95e796f65b26379b0e5c699bacef29f7684f79f/gdal/gcore/gdalopeninfo.cpp#L216 
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 ?

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.