[gdal-dev] GDAL 3.1.4 RC1 available

[Joaquim Manuel Freire Luís]

Even,

I don't think that was the case. I use a build system that resemble a bit homebrew. All packages are built in their own directories and SATAY there. Then I have a batch that creates symlinks do a directory that is the only in the computer path for my builds. So when I rebuild any package it gets automatically updated in my machine. Yes I did rebuild PROJ and GDAL from master as I always do and the problem arise but when I reverted PROJ to a commit only 9 days older (d1a0d95da549f7d32bcd8be408afe1fca62a6fb2), the problem disappeared.

-----Original Message-----
From: Even Rouault <even.rouault at spatialys.com> 
Sent: Tuesday, October 20, 2020 10:01 AM
To: Joaquim Manuel Freire Luís <jluis at ualg.pt>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available

Joaquim,

Yes GDAL 3.1.4 makes use of the new function proj_crs_get_datum_ensemble() of PROJ master (tested by checking PROJ version number to be >= 7.2 since this is queued for the PROJ 7.2 release in a few days). So I suspect you might build GDAL against the header of a recent PROJ master, but at runtime use an older version of the .dll that has not the symbol

Even

> Reverting PROJ to
> 
> d1a0d95da549f7d32bcd8be408afe1fca62a6fb2
> (* Database query: add
> AuthorityFactory::ObjectType::DYNAMIC_GEODETIC_REFERENCE_FRAME and 
> DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work)
 
> Solved the issue.
> 
> -----Original Message-----
> From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Joaquim 
> Manuel Freire Luís
 Sent: Monday, October 19, 2020 11:04 PM
> To: Even Rouault <even.rouault at spatialys.com>; 
> gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available
> 
> Even,
> 
> I'm puzzled with this but after updating and building GDAL+PROJ today
> (master) one of my MEX dlls that depend on GDAL and PROJ started to 
> error with
 
> Invalid MEX-file
> 'C:\progs_cygw\GMTdev\gmt5\compileds\gmt6\VC14_64\bin\gmtmex.mexw64': 
> The specified procedure could not be found.
 
> I managed to trace it to this likely source provided by 
> DependencyWalker. I don't get it  because it seems to indicate that 
> "proj_crs_get_datum_ensemble" is not exported but that is not the 
> case. Any new use of that function?
 
> Joaquim
> 
> -----Original Message-----
> From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Even 
> Rouault
> Sent: Monday, October 19, 2020 3:31 PM
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] GDAL 3.1.4 RC1 available
> 
> Hi,
> 
> So that we can focus on 3.2.0 and onwards, I have prepared a GDAL/OGR 
> 3.1.4 release candidate, which should be the final one in the 3.1 series.
 
> Pick up an archive among the following ones (by ascending size):
> 
>   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
>   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
>   https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip
> 
> A snapshot of the gdalautotest suite is also available :
> 
>   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
>   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip
> 
> GDAL-GRASS plugin:
> 
>   https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz
> 
> The NEWS file is here :
> 
>   https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS
> 
> I'll call for a vote promoting it to final soon if no serious problems 
> are reported before.
 
> Best regards,
> 
> Even
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com 
> _______________________________________________
 gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Spatialys - Geospatial professional services http://www.spatialys.com