Compile PostGIS 2.0 (SVN)

JP Glutting jpglutting at gmail.com
Mon Aug 29 08:12:52 PDT 2011


Thanks Ryan,

I deleted the source directory for postgis 2.0 SVN, started a new shell and
unzipped it, so start over clean. Then I set the environmental variables:

*export CPPFLAGS=-I/opt/local/include
export LDFLAGS=-L/opt/local/lib
export CPATH=/opt/local/include
export LIBRARY_PATH=/opt/local/lib
export CFLAGS="-arch i386 -arch x86_64"
export LDFLAGS="-L/opt/local/lib -arch i386 -arch x86_64" *
*export CC=/opt/local/bin/gcc-4.3
export CXX=/opt/local/bin/g++-4.3
*
and ran

*./configure --with-raster*

But it fails pretty quickly:

*checking build system type... i686-apple-darwin11.1.0*
*checking host system type... i686-apple-darwin11.1.0*
*checking for gcc... /opt/local/bin/gcc-4.3*
*checking for C compiler default output file name... configure: error: C
compiler cannot create executables*
*See `config.log' for more details.*

(I didn't have gcc43 installed, but it even fails on the binary I have in
that directory: gcc-mp-4.4)

However, after taking the the GCC and GXX declarations out, I got an error
from GDAL, and it turned out that GDAL hadn't built properly +universal, so
I rebuilt it and PostGIS compiled correctly.

I'm glad it is finally working. Thanks for all the information, Ryan. I hope
this thread is useful to someone else trying to compile the SVN version of
PostGIS using Macports dependencies.

Cheers,
JP

On Sun, Aug 28, 2011 at 12:33 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Aug 27, 2011, at 16:15, Ryan Schmidt wrote:
>
> >> My thinking was that perhaps postgis (or part of it) was trying to
> compile as i386 and couldn't find the appropriate framework, as it was only
> built x86_64 (which is all I was using). So I built all the dependencies
> +universal, just in case.
> >
> > That is what is happening, and it's because of a bug in our postgresql
> ports, for which I have filed a bug report for you:
> >
> > https://trac.macports.org/ticket/31000
>
> Er, I misspoke. What is happening is that, when you're not telling postgis
> to build universal (you weren't), it builds largely non-universal. Except
> when it includes the results of running pg_config to build the postgresql
> parts, at which point, because of the above bug in pg_config, it tries to
> build universal, which fails when it tries to link that up with
> previously-built non-postgresql-related postgis code that wasn't built
> universal.
>
>
> > Basically the problem is that you are building postgis non-universal, but
> postgresql is installed universal. Either install postgresql non-universal,
> or build postgis universal.
>
> This is still the correct advice.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110829/ce88231e/attachment.html>


More information about the macports-users mailing list