[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