[gdal-dev] Error compiling GDAL from trunk on Mac OS X 10.6.8

Even Rouault even.rouault at mines-paris.org
Fri Mar 15 17:06:46 PDT 2013


Le vendredi 15 mars 2013 23:55:18, Jorge Arévalo a écrit :
> El viernes 15 de marzo de 2013 a las 23:03, Even Rouault escribió:
> > Le vendredi 15 mars 2013 22:53:36, Jorge Arévalo a écrit :
> > > El viernes 15 de marzo de 2013 a las 22:36, Even Rouault escribió:
> > > > Le vendredi 15 mars 2013 20:09:57, Jorge Arévalo a écrit :
> > > > > Hello,
> > > > > 
> > > > > I'm getting an error compiling GDAL from trunk (r25758). I
> > > > > successfully compiled GDAL from trunk before with this configure
> > > > > script:
> > > > > 
> > > > > https://dl.dropbox.com/u/6599273/gdal/configure_gdal.sh
> > > > > 
> > > > > But after last svn update to r25758, I get this error
> > > > > 
> > > > > https://dl.dropbox.com/u/6599273/errors/gdal_trunk_compile_error.lo
> > > > > g
> > > > > 
> > > > > I haven't compiled GDAL on Mac for a while. So, The problem isn't
> > > > > necessarily caused by the last update.
> > > > > 
> > > > > Anyone else with the same problem?
> > > > 
> > > > Cool that someone tests on the Mac and reports.
> > > > 
> > > > Well, I assumed that "extern char** environ" that contains the
> > > > environment variable was available on all POSIX platforms, but
> > > > apparently not.
> > > > 
> > > > http://www.gnu.org/software/gnulib/manual/html_node/environ.html
> > > > suggests me the following patch. Please test and report if it works.
> > > > 
> > > > Index: port/cpl_spawn.cpp
> > > > ===================================================================
> > > > --- port/cpl_spawn.cpp (revision 25734)
> > > > +++ port/cpl_spawn.cpp (working copy)
> > > > @@ -461,8 +461,13 @@
> > > > #include <signal.h>
> > > > #ifdef HAVE_POSIX_SPAWNP
> > > > #include <spawn.h>
> > > > +#ifdef MACOSX_FRAMEWORK
> > > > +#include <crt_externs.h>
> > > > +#define environ (*_NSGetEnviron())
> > > > +#else
> > > > extern char** environ;
> > > > #endif
> > > > +#endif
> > > > 
> > > > #if 0
> > > > /********************************************************************
> > > > **** /
> > > > 
> > > > > Thanks in advance,
> > > 
> > > Thanks! We got to the same solution :-). I've found the same patch in
> > > MacPorts
> > > (http://trac.macports.org/browser/trunk/dports/lang/hugs98/files/patch-
> > > pac kages-base-include-HsBase.h.diff?rev=81676). It worked.
> > > 
> > > I could create a new ticket and attach the patch file. Is it ok?
> > 
> > Or you can commit it directly as you wish since you've commit rights. But
> > the patch are not strictly identical. I tested #ifdef MACOSX_FRAMEWORK
> > whereas the link you provide test #ifdef __APPLE__ . Not sure if they
> > are equivalent in the GDAL context. Perhaps #ifdef __APPLE__ is better
> > and MACOSX_FRAMEWORK too specific to a special flavour of building a
> > shared lib ? Just guessing blindly...
> > 
> > > --
> > > Jorge Arevalo
> > > Freelance developer
> > > 
> > > http://www.krop.com/jorgearevalo
> > > http://about.me/jorgeas80
> > > 
> > > Enviado con Sparrow (http://www.sparrowmailapp.com/?sig)
> 
> Honestly, I'm not sure.
> 
> __APPLE__ is a gcc predefined macro (as listed here
> http://sourceforge.net/p/predef/wiki/OperatingSystems/), and
> MACOSX_FRAMEWORK is defined by GDAL in configure time if the user
> specified --with-macosx-framework and 'Darwin' is present executing uname.
> That option tells GDAL to be constructed as a Mac OS X Framework.
> 
> Both macros are used in the sources. Why do we have 2 options to the same
> thing? Or am I wrong and they have different purposes?

I'd say that for the environ stuff #ifdef __APPLE__ sounds more appropriate ?

> 
> --
> Jorge Arevalo
> Freelance developer
> 
> http://www.krop.com/jorgearevalo
> http://about.me/jorgeas80
> 
> Enviado con Sparrow (http://www.sparrowmailapp.com/?sig)


More information about the gdal-dev mailing list