/usr/local question

Ryan Schmidt ryandesign at macports.org
Wed Apr 4 11:22:18 PDT 2012


On Apr 4, 2012, at 12:42, Glenn English wrote:

> 
> On Apr 4, 2012, at 10:27 AM, Ryan Schmidt wrote:
> 
>> Because /usr/local is searched by default by the compiler and we do not know how to turn that off, MacPorts ports might try to link with libraries you've installed in /usr/local.
> 
> Ah! Thank you; that makes sense. I'll try to stay away from installing libraries there. 
> 
> I just looked, and all that's in mine is perl, python, and ruby -- I'll also keep in mind your explanation when something goes odd with a MacPorts build.
> 
> Is that default search part of the compiler code, or is it because of $PATH?

It is code in the compiler. It's not related to $PATH.

> If Apple doesn't use /usr/local libraries, why would they have anything to do with a compiler that forces that search? That'd result in a lot on badly bent code lying around.

The definition of /usr/local is a directory where users put things they've compiled themselves; things that did not come from the OS vendor. Therefore it is right for Apple to not ship anything in /usr/local, and it's perhaps even reasonable for them to ship a compiler that looks there for dependencies. I didn't think this was an Apple-specific thing; I thought that's just how GCC works, but I don't know for sure.

> This might be overkill, but have you considered adding code to your scripts to mv /usr/local to /usr/localqw (and back at the end)? Or maybe just the lib dir?

I had not considered that. But MacPorts is not always installed as root; when not root, it would not have permission to do that. Also, moving /usr/local is likely to break whatever's installed there. I think the user needs to be the one to understand the consequences of their actions of installing things in /usr/local and be the one to take responsibility for uninstalling those items.

Not everything in /usr/local is necessarily a problem. But we do not want to spend our time analyzing what rogue software is and isn't a problem; we have real actual MacPorts issues that we want to spend our time solving that don't involve rogue software. If a user reports a problem, and the error message or log contents point to something existing in /usr/local, our response will be to make the user remove /usr/local and try again.

I might not be opposed to MacPorts printing a warning if anything is found in /usr/local/{bin,etc,include,lib,libexec,man,sbin,share,var}. But I would probably only want to print that if a port actually failed to build.



More information about the macports-users mailing list