On 2016-10-10 21:50 +0200, Sebastiaan Couwenberg wrote:
> Dear arm64 porters,
>
> The postgis (2.3.0+dfsg-3) upload is failing to build to arm64 because
> its configure check for GDAL failed, specifically:
>
> AC_SEARCH_LIBS([GDALAllRegister], [gdal], [], [AC_MSG_ERROR([could not
> find GDAL])], [])
>
> I can reproduce this issue on the the arm64 porterbox, where I also
> verified that the previous -2 and -1 uploads, which built successfully
> on the buildds, now also fail due to the same issue.
OK. I reproduced it with -2 too, on asachi.
> Can you help me troubleshoot and resolve this issue?
So gdal-config works:
checking for gdal-config... /usr/bin/gdal-config
checking GDAL version... 2.1.1
....
checking for library containing GDALAllRegister... no
and the config snippet is:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define POSTGIS_MAJOR_VERSION "2"
| #define POSTGIS_MINOR_VERSION "3"
| #define POSTGIS_MICRO_VERSION "0"
| #define YYTEXT_POINTER 1
| #define HAVE_IEEEFP_H 0
| #define HAVE_TERMIOS_H 1
| #define HAVE_VASPRINTF 1
| #define HAVE_ASPRINTF 1
| #define HAVE_FSEEKO 1
| #define HAVE_ISFINITE 1
| #define HAVE_GNU_ISFINITE 1
| #define HAVE_ICONV 1
| #define PGSQL_LOCALEDIR "/usr/share/locale"
| #define HAVE_LIBPQ 1
| #define POSTGIS_PGSQL_VERSION 96
| #define HAVE_LIBXML_TREE_H 1
| #define HAVE_LIBXML_PARSER_H 1
| #define HAVE_LIBXML_XPATH_H 1
| #define HAVE_LIBXML_XPATHINTERNALS_H 1
| #define HAVE_LIBXML2 1
| #define POSTGIS_LIBXML2_VERSION "2.9.4"
| #define HAVE_LIBGEOS_C 1
| #define POSTGIS_GEOS_VERSION 35
| #define POSTGIS_SFCGAL_VERSION 13
| #define ENABLE_NLS 1
| #define HAVE_GETTEXT 1
| #define HAVE_DCGETTEXT 1
| #define POSTGIS_PROJ_VERSION 49
| #define HAVE_LIBPROJ 1
| #define HAVE_LIBJSON 1
| #define HAVE_LIBJSON_C 1
| #define POSTGIS_DEBUG_LEVEL 0
| #define POSTGIS_PROFILE 0
| #define POSTGIS_VERSION "2.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1"
| #define POSTGIS_LIB_VERSION "2.3.0"
| #define POSTGIS_BUILD_DATE "2016-10-10 21:08:03"
| #define POSTGIS_SCRIPTS_VERSION "2.3.0"
| #define POSTGIS_AUTOCACHE_BBOX 1
| #define POSTGIS_USE_STATS 1
| #define PCRE_VERSION
| #define POSTGIS_RASTER_MAJOR_VERSION "0"
| #define POSTGIS_RASTER_MINOR_VERSION "1"
| #define POSTGIS_RASTER_MICRO_VERSION "6d"
| #define POSTGIS_RASTER_VERSION "0.1" | #define POSTGIS_RASTER_LIB_VERSION "0.1.6d"
| #define POSTGIS_RASTER_BUILD_DATE "2016-10-10 21:08:03"
| #define POSTGIS_RASTER_SCRIPTS_VERSION "0.1.6d"
| #define POSTGIS_RASTER_WARN_ON_TRUNCATION 0
| #define POSTGIS_GDAL_VERSION 21
| #define HAVE_GDAL_H 1
| #define HAVE_OGR_API_H 1
| #define HAVE_CPL_CONV_H 1
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char GDALAllRegister ();
| int
| main ()
| {
| return GDALAllRegister ();
| ;
| return 0;
| }
configure:17165: aarch64-linux-gnu-gcc -o conftest -I/usr/include/gdal -Wl,-z,relro -Wl,-z,now conftest.c -lgdal -L/usr/lib -lgdal >&5
/usr/lib/libgdal.so: undefined reference to `non-virtual thunk to CryptoPP::AdditiveCipherTemplate<CryptoPP::AbstractPolicyHolder<CryptoPP::AdditiveCipherAbstractPolicy, CryptoPP::OFB_ModePolicy> >::Seek(unsigned long long)'
/usr/lib/libgdal.so: undefined reference to `non-virtual thunk to CryptoPP::AdditiveCipherTemplate<CryptoPP::AbstractPolicyHolder<CryptoPP::AdditiveCipherAbstractPolicy, CryptoPP::CTR_ModePolicy> >::Seek(unsigned long long)'
/usr/lib/libgdal.so: undefined reference to `CryptoPP::RandomNumberGenerator::GenerateIntoBufferedTransformation(CryptoPP::BufferedTransformation&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long long)'
/usr/lib/libgdal.so: undefined reference to `CryptoPP::CTR_ModePolicy::SeekToIteration(unsigned long long)'
/usr/lib/libgdal.so: undefined reference to `non-virtual thunk to CryptoPP::CTR_ModePolicy::SeekToIteration(unsigned long long)'
/usr/lib/libgdal.so: undefined reference to `CryptoPP::AdditiveCipherTemplate<CryptoPP::AbstractPolicyHolder<CryptoPP::AdditiveCipherAbstractPolicy, CryptoPP::OFB_ModePolicy> >::Seek(unsigned long long)'
so some symbols are missing from the gdal library. Some crypto functions?
gdal uploads to unstable were 09-03 and 09-07
last working postgis build was 10-03 (2.3.0+dfsg-2)
configure in that said "checking for library containing GDALAllRegister... none required"
sugesting that the offending test was skipped? Any idea why that might be?
same for -1 on 09-26
looking at other arches that seems to be the 'normal' text.
So this is all rather odd. gdal doesn't seem to have changed since
working -1 and -2 builds, but now the test is giving different results.
comparing the OK -2 build log and failed -3 build log there isn't much
changed in the environment that seems likely to be relevant, but the autoreconf behaviour of debhelper has changed a bit
we used to get:
debian/rules build-arch
dh_testdir
dh_prep -s
dh_prep: -s/--same-arch is deprecated; please use -a/--arch instead
dh_autoreconf autoconf
dh_autotools-dev_updateconfig
now we get:
dh build-arch --with autotools_dev,autoreconf
dh_testdir -a
dh_update_autotools_config -a
dh_autotools-dev_updateconfig -a
debian/rules override_dh_autoreconf
make[1]: Entering directory '/«BUILDDIR»/postgis-2.3.0+dfsg'
dh_autoreconf autoconf
make[1]: Leaving directory '/«BUILDDIR»/postgis-2.3.0+dfsg'
debian/rules override_dh_auto_configure
make[1]: Entering directory '/«BUILDDIR»/postgis-2.3.0+dfsg'
OK, that's not an actual change in the rules file so probably a red herring.
Checking the gdal arm64 build log, it says
cryptopp=yes
There is no obvious complaining about that going wrong.
So, looking at the configure test. 'non-required' comes from:
for ac_lib in '' gdal; do
if test -z "$ac_lib"; then
ac_res="none required"
It's not clear to me if in the past this test has in fact been
skipped, but it no longer is, and so we are noticing some underlying
issue for the first time.
installing the dbgsym package for libgdal20, shows that
GDALAllRegister does exist. But for some reason the cryptoPP functions
(which postgis may not care about?) have a problem. Anything to do
with C++ symbols always makes me come out in hives...
Seems to me that the issue is probably actually in gdal, rather than postgis, although why the configure behaviour has changd remains a mystery.
It's now way past bedtime so this'll have to do for now.
Hopefully this will help someone.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Attachment:
signature.asc
Description: Digital signature