search

petere / pex

light-weight package manager for PostgreSQL
Other
97 stars 2 forks source link

Postgis on mac compile issue with gettext #2

Open joaoponceleao opened 9 years ago

joaoponceleao commented 9 years ago

By default, Postgis will try to compile with gettext support. This creates a problem on macs (at least on mavericks). Whilst OS X provides the gettext library, it is incomplete and missing certain dylibs. As a result, Postgis' .configure will try to compile with gettext support and fail.

There are two ways around this:

  1. Remove gettext support for a default install (possibly also providing a flag --with-gettext for those who need it). This requires a change to the recipe (or can we add compilation flags to pex install ?).
  2. Install gettext via homebrew followed by brew link --force gettext. One should unlink gettext after building postgis as this will conflict with the standard OS X library (as per homebrew's caveats).

Option 1 is probably better. From Postgis' installation reference:

--with-gettext=no By default PostGIS will try to detect gettext support and compile with it, however if you run into incompatibility issues that cause breakage of loader, you can disable it entirely with this command. Refer to ticket http://trac.osgeo.org/postgis/ticket/748 for an example issue solved by configuring with this. NOTE: that you aren't missing much by turning this off. This is used for international help/label support for the GUI loader which is not yet documented and still experimental.

I'm not sure how to implement such a change to pex's postgis recipe, so I can't provide a PR. Either way, leaving this issue here in case people run into trouble.

joao.

petere commented 9 years ago

I think the preferred fix is for PostGIS to have a more accurate gettext detection.

The proposal to install gettext via Homebrew is also good. I would not worry too much about the Homebrew caveats. I have installed gettext this way and it's never been a problem.

Adding a way in Pex to override a package's configuration flags would be a good feature, but there aren't many packages that would make use of it at the moment, so I'd try the other solutions first.