i686-pc-linux-gnu-g++ -ggdb -O1 -O2 -O3 -pipe -march=native -fdiagnostics-show-option -fPIC -Wall -DOGR_ENABLED -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/port -Iexternal/include -I/usr/ -I/usr//include -DHAVE_CURL -DHAVE_LIBZ -c -o cpl_vsil_gzip.o cpl_vsil_gzip.cpp In file included from cpl_minizip_unzip.h:71:0, from cpl_vsil_gzip.cpp:84: cpl_minizip_ioapi.h:48:44: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:49:44: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:50:45: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:51:47: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:52:44: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:53:45: error: expected initializer before ‘OF’ cpl_minizip_ioapi.h:54:49: error: expected initializer before ‘OF’ The OF macro appears to have changed to _Z_OF in recent zlib.
do not just change the code to use _Z_OF. add a local OF define to the pkg: #define OF(x) x
I have the same issue. Is there a patch?
sed -i '1i#define OF(x) x' `find -name cpl_minizip_ioapi.h`
Thanks SpanKY, the patch worked for me in the attached ebuild.
Created attachment 287407 [details] patched gdal-1.8.1.ebuild to work with openmpi and recent zlib
New ebuild works for me, too. It does give these warnings, no idea if they matter, but I'll repost if I have any problems :) * python_mod_optimize(): /gdal.py does not exist * python_mod_optimize(): /ogr.py does not exist
Created attachment 287607 [details, diff] gdal-lib-OF.patch Similar, as a source patch.
To clarify, the change from OF to _Z_OF is a Gentoo patch since sys-libs/zlib-1.2.5-r1: sed_macros() { # clean up namespace a little #383179 # we do it here so we only have to tweak 2 files sed -i -r 's:\<(O[FN])\>:_Z_\1:g' "$@" || die }
I'm not sure I understand either one of these; wasn't there something besides zlib (ie, with fewer dependencies) to "fix" wrt possible name collisions? Doesn't the zlib header change pretty much break everything built against the previous ("normal") zlib packages? As for the mpi change, gdal doesn't care about whether hdf5 is built with parallel support or not, nor should it. Hacking the gdal build to use the mpi wrappers wasn't the answer for missing mpi* symbols in libhdf5, nor is it the answer here. If there's an issue with the openmpi package, then please file a bug against openmpi.
This is fixed in the latest rev bump, along with the python stuff in pkg_pre/post. As far as coupling gdal and mpi, that would be a bad idea...
Bug is still present in sci-libs/gdal-1.6.3-r1 :(
