Changes between Version 136 and Version 137 of FAQ


Ignore:
Timestamp:
May 30, 2014, 1:28:06 AM (10 years ago)
Author:
neverpanic (Clemens Lang)
Comment:

Extend #usrlocal by the possible use of trace mode

Legend:

Unmodified
Added
Removed
Modified

  • FAQ

    v136 v137  
    7575
    7676=== So with MacPorts under /opt/local I can use /usr/local freely? === #usrlocal
    77                                                                                
     77
    7878No, not entirely. Even with MacPorts living elsewhere, `/usr/local` can still interfere.
    7979Some software (especially the GNU auto* tools and gcc) looks into `/usr/local` for external headers, libraries, and binaries. Certain ports might (and do) fail to build because during their build something incompatible is found and picked up
    … …  
    8383that it found and picked up in `/usr/local` you will probably be advised to temporarily rename
    8484`/usr/local` to make it disappear entirely for the duration of the build.
    85 Obviously, this wouldn't be possible to do if MacPorts itself lived under `/usr/local`.         
    86  
     85Obviously, this wouldn't be possible to do if MacPorts itself lived under `/usr/local`.
     86
     87Note that starting with 2.3.0, MacPorts can automatically hide `/usr/local` (and all other files a port does not depend on) from ports' build systems. This feature is called trace mode and is activated by providing the `-t` flag to `port`, e.g.
     88{{{
     89sudo port -t install <portname>
     90}}}
     91You'll notice a small performance penalty when using trace mode, and a very little number of ports will fail to build due to the changes in the environment (currently, only the `go` port is known to be affected). Warnings about sandbox violations are normal when using trace mode. If a port fails to build in trace mode, the problem is very likely a bug. You should file a ticket if none exists yet.
     92
    8793=== How do I remove or uninstall MacPorts? === #uninstall
    8894