Opened 5 years ago

Last modified 3 years ago

#55831 assigned defect

postgis2 fails to compile on Snow Leopard

Reported by: fvaccari Owned by: Veence (Vincent)
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: snowleopard Cc:
Port: postgis2


I had to apply a modification to postgis2 Portfile in order for it to compile under Snow Leopard. I attach here the modified Portfile, where I added this code

build.args-append       CC=${} \
                        CXX=${configure.cxx} \


build.args                  ICONV_LDFLAGS='-L${prefix}/lib -liconv'

I'm not sure this is the correct solution, or if it breaks on newer systems, but it solved my issue...

Attachments (2)

postgis2.Portfile.ok (5.0 KB) - added by fvaccari 5 years ago.
postgis2.main.log (158.9 KB) - added by fvaccari 5 years ago.
The log with the error

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by fvaccari

Attachment: postgis2.Portfile.ok added

Changed 5 years ago by fvaccari

Attachment: postgis2.main.log added

The log with the error

comment:1 Changed 5 years ago by ryandesign (Ryan Schmidt)

Cc: vince@… removed
Keywords: snowleopard added; postgis2 SnowLeopard removed
Owner: set to Veence
Status: newassigned

I see the port has selected llvm-gcc-4.2:


It uses this compiler for a lot of the build, but then tries to use gcc-4.2 when building the postgis directory:

:info:build ---- Making all in postgis
:info:build make[1]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_postgis2/postgis2/work/postgis-2.4.3/postgis'
:info:build /usr/bin/gcc-4.2 -I../liblwgeom -pipe -Os -Diconv=libiconv -Diconv_open=libiconv_open -Diconv_close=libiconv_close -arch x86_64  -I../libpgcommon  -I/opt/local/include   -I/opt/local/include/libxml2    -I/opt/local/include -fPIC -I. -I./ -I/opt/local/include/postgresql10/server -I/opt/local/include/postgresql10/internal  -I/opt/local/include -I/opt/local/include/libxml2  -I/opt/local/include  -c -o postgis_module.o postgis_module.c
:info:build make[1]: /usr/bin/gcc-4.2: No such file or directory

It is wrong for the build system to be disobeying MacPorts' directives about which compiler to use. If your proposed change works, that's great, and we could use that, but we might also want to dissect the build a bit to see why it is doing this wrong thing in the first place. It may be inheriting the compiler value from one of its dependencies for which you received a binary from our build server. /usr/bin/gcc-4.2 is the compiler used on our Snow Leopard build server because that is the default compiler with Xcode 3.2.6 and that is the latest free version of Xcode for Snow Leopard. I assume that compiler does not exist on your system because you are or were a paid Apple developer and therefore have access to and have installed Xcode 4.2 for Snow Leopard which does not contain that compiler anymore.

The problem is not Snow Leopard-specific per se, but Snow Leopard is the only system on which you're likely to see the problem because Snow Leopard is the only macOS version on which you get a different default compiler depending on which Xcode version you install.

comment:2 Changed 5 years ago by fvaccari

Indeed I have Xcode 4.2

xcodebuild -version
Xcode 4.2
Build version 4C199

I'm afraid there could be bad side effects if I would downgrade to Xcode 3.2.6, but if there is a way to add the missing compiler to my test machine, I'd be happy to give it a try and see if that works with the original Portfile

comment:3 Changed 5 years ago by Veence (Vincent)

I’m sorry I’m a bit late to this. Problem is, you’re a bit out of luck because I don’t have a Snow Leopard machine at hand. Ryan has. So if he tells me exactly what to do, I’ll be happy to oblige.

comment:4 Changed 3 years ago by fvaccari

Sitting with @mojca behind the machine.

In the meantime the default compilers changed and this port is still problematic.

One further problem we discovered is that we had to add a configure flag --with-gdalconfig=${prefix}/bin/gdal-config next to

variant raster description {Build raster support} {
    depends_lib-append      port:gdal

else it didn't find the gdal headers at all.

Now, after adding that flag, the problem remained with

checking for OGR enabled... yes
checking gdal.h usability... no
checking gdal.h presence... yes
configure: WARNING: gdal.h: present but cannot be compiled
configure: WARNING: gdal.h:     check for missing prerequisite headers?
configure: WARNING: gdal.h: see the Autoconf documentation
configure: WARNING: gdal.h:     section "Present But Cannot Be Compiled"
configure: WARNING: gdal.h: proceeding with the compiler's result
checking for gdal.h... no
configure: error: could not find GDAL headers

which seems to boil down to

configure:17664: /usr/bin/gcc-4.2 -c -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -pipe -Os -arch x86_64 -I/opt/local/include conftest.c >&5
In file included from /opt/local/include/gdal.h:45,
                 from conftest.c:105:
/opt/local/include/cpl_port.h:709:23: error: x86intrin.h: No such file or directory
Version 0, edited 3 years ago by fvaccari (next)

comment:5 Changed 3 years ago by kencu (Ken)

old versions of gcc don't have that header, but new versions do, and all clangs that we care about should have it too.

$ locate x86intrin.h
Note: See TracTickets for help on using tickets.