/usr/local question

[Jan Stary]

On Apr 05 04:13:44, Jeremy Lavergne wrote:
> The thread has pointed out that there would not be an issue
> if that were the case: it appears Gnu toolchain puts /usr/local first.

Even if the build tools put /usr/local before /usr,
the example still stands: I don't have /usr/local at all.
I have an old, incompatible version of openssl in
/usr/lib/libssl.*, and a port that fails to build
because it picks that up.

What happens then? Should I temporarily rename /usr
so that the port does not pick that up and builds successfully?


> >>> Am 05.04.2012 um 10:25 schrieb Jan Stary <hans at stare.cz>:
> >>>
> >>>> On Apr 05 09:00:44, Jan Stary wrote:
> >>>>> However, if a given port silently picks up something
> >>>>> incompatible in /usr/local, if might fail and often will.
> >>>>>
> >>>>> Having macports isolated in /opt/local DID NOT save you from this.
> >>>>> Removing /usr/local is what did.
> >>>>
> >>>> One more point to this: what if the colliding, incompatible
> >>>> software that stops a given port from building successfully
> >>>> is not found under /usr/local, but in /usr, which is
> >>>> even more prominently recognized by various build tools.
> >>>>
> >>>> That's not made up: /usr/lib/libssl.*
> >>>> Say the port requires a newer version of openssl
> >>>> than what /usr/lib/libssl.* provides.
> >>>>
> >>>> That's the same situation as with a port not building
> >>>> because some incompatbile software was found and
> >>>> picked up from /usr/local; except now it is /usr.
> >>>>
> >>>> What is the advice here?
> >>>> Ceratinly not to temporarily rename /usr.
> >>>>
> >>>> I argue that temporarily removing /usr/local is just as bad,
> >>>> and the problem of a port picking bad stuff from /usr/local
> >>>> is that given port's defect that needs to be fixed before
> >>>> the port gets built; not a reason to remove /usr/local.
> >>>>
> >>>> (Which doesn't change the fact that /opt/local is a better prefix,
> >>>> I am over that already.)