cairo install fails (was: Building cairomm (inkscape dependency) fails)

[Mike McAngus]

On Apr 22, 2008, at 2:40 AM, Ryan Schmidt wrote:

> On Apr 21, 2008, at 5:03 AM, Mike McAngus wrote:
>
>> On Apr 21, 2008, at 12:17 AM, Ryan Schmidt wrote:
>>
>>> On Apr 20, 2008, at 7:25 PM, Mike McAngus wrote:
>>>
>>>> I did not consciously install anything in /usr/local.  Looking  
>>>> in there, I see
>>>> *  ClamXav directory.  I could probably replace ClamXav with  
>>>> clamav from MacPorts if I was willing to give up the UI.
>>>> *  A "SourceGuard" directory which I don't recognize.  All of  
>>>> its files have Created, Modified and Accessed dates of 9/3/03.
>>>
>>> These are not a problem. It's only things installed "directly"  
>>> in /usr/local (that is, that were compiled with --prefix=/usr/ 
>>> local or which install into prefix /usr/local by default) which  
>>> can cause problems.
>>>
>>>> *  A bin, include, lib, man and share directory.  There are many  
>>>> files in those directories.
>>>
>>> These are the potentially problematic files, especially the bin,  
>>> include and lib directories.
>>
>> OK.  So how do I determine which of the 66 files in those three  
>> directories are problematic?
>
> Different ports have different dependencies. Suppose you want to  
> install port A, and it depends on port B which depends on port C.  
> But you've manually installed an older version of C in /usr/local.

I reiterate, I have not consciously installed anything in /usr/ 
local.  Anything that is there was put there by some application in  
some .dmg that I installed.  I'm a Java web developer, and I have a  
separate disk drive named Projects where I do all my personal coding.

> MacPorts will dutifully follow the dependency chain, and into its  
> prefix (usually /opt/local) it will install C, then B, then A, only  
> when it tries to install B, the compiler will probably find some  
> parts of the older C in /usr/local, because the compiler always  
> looks in /usr/local and we don't know how to tell it not to. But it  
> may still find other parts of the newer C in /opt/local. If the  
> versions don't match, this may result in a failure to build B, for  
> example if B is trying to use new features of C present in the /opt/ 
> local version but not in the older /usr/local version.
>
> To resolve this problem, you must remove the files of C that are  
> in /usr/local. There is no general-purpose automated way to  
> discover which files belong to C. You have to dissect the  
> installation script for C, ask the authors of C, etc.
>
> Or in your case the file in /usr/local wasn't conflicting with one  
> provided with another port but with one provided by the system.
>
> In other words, if you want to mix software in /usr/local with  
> software in MacPorts, you have to know what you're doing, and it's  
> too much effort for us (or at least for me) to support any  
> configuration where MacPorts users also install software in /usr/ 
> local.

When it comes to Java, Javascript and HTML, I know what I'm doing.   
When it comes to manipulating files in magic *nix directories, I just  
don't do it without explicit instructions.  I have no recollection of  
any explicit instructions involving /usr/local

>> And, how do I ensure that if I make files in those directories  
>> unavailable I won't break something else?
>
> You need to know what software you installed into /usr/local and  
> what you use it for.

Until this past week I had no idea that I had installed anything in / 
usr/local/.  I know what ClamXav is, but not what SourceGuard is or  
how it got there (and I'm researching what I have to do to get rid of  
it).  Now, I have files in /usr/local/bin, /usr/local/lib and usr/ 
local/share and I don't know what uses them.

> Hopefully the software you installed in /usr/local is also  
> available with MacPorts, so you can move /usr/local aside, install  
> the software you need using MacPorts, and that's it. If ports do  
> not exist, you can make or request them.
>
> When I was moving to MacPorts, I moved my /usr/local aside and as I  
> found things that were broken I installed the appropriate ports.

Since the /usr/local/clamXav directory has its own bin, include and  
lib directories, I've decided to move everything else under /usr/ 
local to a new /usr/local.hold directory.  Now I get to wait and see  
what breaks.  Joy!