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