cairo install fails (was: Building cairomm (inkscape
dependency) fails)
Mike McAngus
sourceforge.rocks at xemaps.com
Tue Apr 22 03:38:24 PDT 2008
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!
More information about the macports-users
mailing list