Postgis & libiconv problem

[Daniel J. Luke]

On Sep 7, 2007, at 11:30 AM, Jeff Stubbs wrote:
> After installing, I checked it's dependencies with:
>
> apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp
> /opt/local/bin/pgsql2shp:
>         /usr/lib/libiconv.2.dylib (compatibility version 5.0.0,  
> current version 5.0.0)
>         /opt/local/lib/postgresql82/libpq.5.dylib (compatibility  
> version 5.0.0, current version 5.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 88.1.10)
>
> After uninstalling & cleaning, I modified the the PortFile to build  
> without libiconv, resulting in:
>
> apollo:~ jeff$ otool -L /opt/local/bin/pgsql2shp
> /opt/local/bin/pgsql2shp:
> 	/opt/local/lib/postgresql82/libpq.5.dylib (compatibility version  
> 5.0.0, current version 5.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
> version 88.1.10)

That looks like it worked (at least the way you describe it) ... it  
built without libiconv.

> Thinking I was doing something wrong, I backed out the 1.3.1  
> version and installed MP's included 1.2.1 version. otool reports  
> the same findings.
>
> Read thru the nu MP guide, trying everything that looks like it  
> would modify the configure & build environment. No luck.

Usually, it's just a matter of setting an argument that gets passed  
to configure (something like --with-iconv=${prefix}) if the project's  
configure script doesn't have an option like that, though, you have  
to do some more work to figure out how to coerce it's build system to  
do what you want.

> I did search the source folder with BBEdit looking for references  
> to "iconv" and found about 149 of them, in configure, configure.in  
> and makefile.config.in. Nothing stood out as direct reference to  
> libiconv in /usr/lib.

It's probably looking for iconv, and just searching /usr/lib before  
looking in ${prefix}/lib

> Before I attempt blindly modifying these files, has any experienced  
> users/developers dealt with this type of problem before?
>
> Second, am I being too much of a purist, and should just accept the  
> linking in /usr/lib?

Ideally, you should make it link against the macports version. If you  
can't figure out a way to make it work, it might be acceptable to  
have the version that doesn't link with iconv. You really don't want  
to have it linking against a non-macports iconv if at all possible.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20070907/4ab949f0/PGP.bin