On 2016-10-13 15:52, Bas Couwenberg wrote:
On 2016-10-13 15:48, Wookey wrote:
On 2016-10-12 18:57 +0100, Wookey wrote:
On 2016-10-11 08:16 +0200, Sebastiaan Couwenberg wrote:
> > Seems to me that the issue is probably actually in gdal, rather
> > than postgis, although why the configure behaviour has changd
> > remains a mystery.
> The configure behaviour is weird indeed. On the other architectures
> "none required" remains the result for this test.
I looked at the actual configure stuff for this and couldn't really
grok when that came out as the result.
> The CryptoPP symbols seem to have changed with the recent update of
> libcrypto++ from 5.6.3-8 to 5.6.4-1. Which did not create this problem
> on the other architectures though.
> Perhaps rebuilding gdal with the new libcrypto++ on arm64 will be
> sufficient to fix this issue?
That seems quite likely. It might just be the senstivity of C++
symbols to compiler changes. Unfortunately so far as I know one can't
test such a thing on the porter boxes (because there is no way to
unstall the local gdal you just built due to lack of root rights).
So I have got my local arm64 box going again and will test this
tomorrow (home time now).
OK. Yep, just rebuilding gdal (and installing the resulting
libgdal-dev, libgdal20), fixes the postgis configure.
I'll schedule a binNMU.
Thanks for the confirmation. A binNMU won't be required, since a new
gdal revision was uploaded today which re-enabled the MySQL/MariaDB
While a rebuild of gdal on arm64 is not required, postgis does need to
be rebuilt with the new gdal revision.
Can you schedule a dep-wait for libgdal-dev (>= 2.1.1+dfsg-5) to retry
to postgis build?