[MacPorts] #64141: gdal @3.3.1_2+postgresql13+proj8: Crash with GeoTIFF that uses JPEG compression

MacPorts noreply at macports.org
Fri Nov 18 21:56:13 UTC 2022


#64141: gdal @3.3.1_2+postgresql13+proj8: Crash with GeoTIFF that uses JPEG
compression
-------------------------+----------------------
  Reporter:  bal-agates  |      Owner:  Veence
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:              |   Keywords:
      Port:  gdal        |
-------------------------+----------------------

Comment (by bal-agates):

 I recently upgraded all of my ports and this issue is still valid.  A
 better issue title would be "gdal generates runtime error with GeoTIFF
 that uses JPEG compression".  For example

 {{{
 $ gdal_translate AZ_Sahuarita_314990_1958_62500_geo.tif -of GTiff j.tif
 ERROR 1: JPEGLib:Wrong JPEG library version: library is 62, caller expects
 80
 Assertion failed: (sp->cinfo.comm.is_decompressor), function
 JPEGSetupDecode, file tif_jpeg.c, line 962.
 zsh: abort
 }}}

 In the above JPEGLIb version 62 comes from the gdal built-in and version
 80 comes from libjpeg (port libjpeg-turbo).  The gdal portfile has "-with-
 jpeg=internal".  Possibly cmake is finding and using the JPEGLib version
 from the libjpeg header file when building applications like
 gdal_translate?  Or multiple objects with same name get randomly selected
 during linking?  Note when gdal variant +proj8 is built one dependency
 chain is gdal -> proj8 -> tiff -> libjpeg-turbo so likely multiple JPEG
 library objects with the same name when building applications.  QGIS3
 includes other libraries that depend on libjpeg-turbo.

 This problem is still causing the latest qgis3 @ 3.28.0 to ungracefully
 crash when importing a GeoTIFF with JPEG compression.  That crash is
 probably just a result of not handling the gdal error well.

 I tried my old fix of modifying the portfile with the changes in
 <Portfile.patch.2>.  This seemed to fix gdal_translate, however, QGIS3
 failed to build.  I do not understand the new QGIS3 build failure.

 {{{
 ld: warning: -undefined dynamic_lookup may not work with chained fixups
 make[2]: Leaving directory
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis3/qgis3/work/build'
 [ 69%] Built target python_module_qgis__core
 make[1]: Leaving directory
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis3/qgis3/work/build'
 make: *** [all] Error 2
 }}}

 I haven't been able to find much on "-undefined dynamic_lookup may not
 work with chained fixups" and it is curious that a warning causes the
 build to stop.  I believe this is related to recent changes in the Xcode
 14 compiler.  I was able to work through that by adding the linker switch
 "-Wl,-no_fixup_chains" but then ran into crash on startup.  Not sure how
 to debug further.

 My current build environment

 {{{
 macOS 12.6 (Monterey)
 $ clang++ --version
 Apple clang version 14.0.0 (clang-1400.0.29.202)
 Target: arm64-apple-darwin21.6.0
 Thread model: posix
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/64141#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list