Moving X11 install into their own subdirectory

[Jeremy Huddleston]

On Mar 17, 2009, at 11:33, Blair Zajac wrote:

> Blair Zajac wrote:
>> I've asked ZeroC to suggest an alternate name for their shared  
>> library and I think the only solution is to rename their shared  
>> library.
>
> A reply from ZeroC on this:
>
> > On MacOS X, libIce.dylib is just a symbolic link to libIce.33.dylib,
> > itself a symbolic link to libIce.3.3.0.dylib and soon
> > libIce.3.3.1.dylib, and this symbolic link should be used only when
> > linking an application, and not at runtime.
> >
> > So the issue occurs if you're using a case-insensitive file  
> system, and:
> >  - you're building an application that links with both libICE and  
> libIce
> > (which would seem uncommon), or
> >  - all your library symbolic links are installed in the same  
> directory
> > (e.g. /usr/lib).
> >
> > At first glance, my preference in this case would be to rename  
> only the
> > conflicting symbolic link, but not the symbolic links/libraries it
> > points to, for example: libZeroCIce.dylib -> libIce.33.dylib ->
> > libIce.3.3.0.dylib
> >
> > and then of course adjust your makefiles to use -lZeroCIce instead  
> of -lIce.
>
> Any comments on this approach?

Curious... Why is it libIce.33.dylib and not libIce.3.dylib as the  
libIce.3.3.0.dylib seems to indicate it should be?

Is it built using libtool?  If so, that seems really inconsistent.   
What does 'otool -L /opt/local/lib/libIce.33.dylib' say?

This is a "good enough" solution for the short term.  libICE is at  
libICE.6.dylib, so we just need to watch to make sure there's never  
conflict between the two.

Why not just go one step further and actually rename the dylibs  
libZeroCIce.33.dylib and libZeroCIce.3.3.0.dylib?  That seems safer,  
easier, and less confusing.