Re: [Buildroot] [PATCH v3] package/libgdal: new package

From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Dominik Michael Rauh <dmrauh@posteo.de>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3] package/libgdal: new package
Date: Sun, 25 Jul 2021 21:37:03 +0200	[thread overview]
Message-ID: <20210725213703.30d03455@windsurf> (raw)
In-Reply-To: <20210528152936.368915-1-dmrauh@posteo.de>

Hello Dominik,

Thanks for your contribution, see below for some comments, actually
just one main comment.

On Fri, 28 May 2021 15:29:36 +0000
Dominik Michael Rauh <dmrauh@posteo.de> wrote:

> +# libgdal fails to detect NEON support on aarch64 or ARM platforms
> +# resp. VSX support on PowerPC based platforms. While linking an
> +# application with libgdal.so, we get an undefined reference to
> +# png_init_filter_functions_neon resp. png_init_filter_functions_vsx.
> +# Some files are missing in the libpng bundled with libgdal, in
> +# particular arm/arm_init.c and powerpc/powerpc_init.c, so disable NEON
> +# and VSX support completely when using libgdal's internal libpng.
> +
> +ifeq ($(BR2_PACKAGE_LIBPNG),y)
> +LIBGDAL_DEPENDENCIES += libpng
> +LIBGDAL_CONF_OPTS += --with-png=$(STAGING_DIR)/usr
> +else
> +LIBGDAL_CONF_OPTS += --with-png=internal
> +LIBGDAL_CPPFLAGS += -DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX_OPT=0
> +endif

If libgdal can use an external png, then we only want to use the
external libpng, so libpng should be a mandatory dependency (I've tried
building using --without-png, and it fails).

However, you really need to look at the other configure options, and
handle them, at least by explicitly disabling the features.

It seems like there are a number of other libraries for which libgdal
is by default using an internal copy, and where we will want to use the
external library itself:

  DODS support:              no
  ECW support:               no
  Expat support:             no
  EXR support:               no
  FGDB support:              no
  FreeXL support:            no
  GEORASTER support:         no
  GEOS support:              no
  Google libkml support:     no
  GRASS support:             no
  GTA support:               no
  HDF4 support:              no
  HDF5 support:              no
  HDFS support:              no
  HEIF support:              no
  INFORMIX DataBlade support:no
  Ingres support:            no
  JP2Lura support:           no
  JPEG 12 bit:               yes
  JPEG-in-TIFF 12 bit:       yes
  JPEG JasPer support:       no
  JPEG-Lossless/CharLS:      no
  Kakadu support:            no
  Kea support:               no
  LERC support:              internal
  libdeflate support:        no
  LIBGEOTIFF support:        internal
  LIBGIF support:            internal
  LIBJPEG support:           internal
  LIBLZMA support:           no
  LIBPNG support:            no
  LIBTIFF support:           internal (BigTIFF=yes)
  libxml2 support:           no
  LIBZ support:              internal
  MDB support:               no
  MongoCXX v3 support:       no
  MongoDB support:           no
  MrSID/MG4 Lidar support:   no
  MrSID support:             no
  MSG support:               no
  MySQL support:             no
  NetCDF support:            no
  OCI support:               no
  ODBC support:              no
  OGDI support:              no
  OpenCL support:            no
  OpenJPEG support:          no
  PCIDSK support:            internal
  PCRaster support:          internal
  PCRE support:              no
  PDFium support:            no
  Podofo support:            no
  Poppler support:           no
  PostgreSQL support:        no
  QHull support:             internal
  Rasdaman support:          no
  RasterLite2 support:       no
  RDB support:               no
  SFCGAL support:            no
  SOSI support:              no
  SpatiaLite support:        no
  SQLite support:            no
  Teigha (DWG and DGNv8):    no
  TileDB support:            no
  userfaultfd support:       yes
  WebP support:              no
  Xerces-C support:          no
  ZSTD support:              no

Again, you don't need to support all those optional dependencies, but
for the ones you don't handle in libgdal.mk, make sure to pass
--without-<foo> so that libgdal doesn't pick it up "by chance".

Could you improve your package submission according to these guidelines?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot