MacPorts, X11 and /opt/local/lib clashing libraries

[Clemens Lang]

Hi,

On Wed, May 15, 2013 at 03:48:45PM -0700, Greg Earle wrote:
> Our software is currently Solaris and Linux-based with an X Windows
> component (some of which uses OpenMotif).  We have a prototype Mac
> port built by the lead developer and he installed OpenMotif directly
> from the source (www.ist-inc.com) into "/usr/OpenMotif".

/usr is Apple Land. Use /usr/local (bad choice though, because of
Homebrew, but that's nothing we have any influence on), or
/opt/OpenMotif for these kind of things.

> Does anyone use MacPorts for X11 stuff?  I would prefer to use
> MacPorts, but it looks to me like if I install the "openmotif" port,
> it sucks in all sorts of other dependent X11 ports and to be honest
> given that Apple has "blessed" XQuartz 2.7.4 I would prefer to be
> compiling/linking against the XQuartz stuff instead.

MacPorts does not install an X server by default (unless you explicitly
ask it to, and if you do so, you'll get one built from the same sources
as XQuartz). The dependencies you see are probably X libraries. MacPorts
has a policy on the libraries it adheres to in this case:
  http://trac.macports.org/wiki/FAQ#ownlibs

> I'm also wary of things like getting an updated "libiconv" in the
> bargain and having that get sucked in first (via $LD_LIBRARY_PATH
> perhaps) causing it to blow up our build scripts up because "tcsh"
> (don't ask!) needs the system "libiconv", and it can't have the
> MacPorts-installed one ahead of it in the library search path.

Linking on Macs works significantly different from what you might be
used to on Linux. There is no direct equivalent of $LD_LIBRARY_PATH, but
libraries are usually referenced by absolute path on OS X. That means
installing a new libiconv in /opt/local will _not_ cause other binaries
to use it, unless you re-link them or do some magic with
install_name_tool(1). This might happen, if you set $DYLD_LIBRARY_PATH,
but it is very often a bad idea to do so on OS X and I wouldn't
recommend its usage (and it's probably unnecessary in your case anyway).

HTH,
-- 
Clemens Lang