CPATH, CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, possibly LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, and any other similar variables I may not yet know about, and give advice about the scenarios in which one might want to use each of them, or point to a document where such explanations are already made?
As I understand it (if anyone else knows better, please correct me), it works like this: 1. Whether preprocessing, compiling or linking, and whether it is C, C ++ or Objective-C code, the relevant GCC program searches paths in the following order: (a) those specified by options on the command line (e.g. via -I and - L arguments), in the order in which they appear; (b) those specified in relevant environment variables when the compiler runs; and finally (c) those coded into GCC when it was compiled. 2. There are _three_ types of environment variables that we have to worry about here. (a) CPPFLAGS, CXXFLAGS, CFLAGS and LDFLAGS are read by make (_not_ GCC), and make takes their contents and adds them _as flags on the command line_ to the relevant GCC program. Thus their contents effectively fall into 1(a) above. If the package uses something _other_ than make to build it, these variables may work differently, or not at all. (If you have both configure.env and configure.args set, they _both_ get inserted; the order depend on the Makefile contents, but it's usually configure.env first.) (b) C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH, CPATH and LIBRARY_PATH are environment variables that the relevant GCC program reads for search paths in 1(b) above. (Respectively, they are searched when preprocessing C, preprocessing C++, preprocessing Objective-C, preprocessing any of these, and when linking.) Both 2(a) and 2(b) only affect things at _compile_ time, i.e. they only make a difference if they are in the environment of the relevant GCC program when it is run to build the program. (c) DYLD_LIBRARY_PATH, DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH specify extra paths to be searched for dynamic libraries when linking _at runtime_, i.e. they only make a difference if they are in your environment when you _run_ the program, and they can override whatever the original compilation intended. (DYLD_LIBRARY_PATH is the Darwin equivalent of LD_LIBRARY_PATH on every other Unix; I don't think other Unices have equivalents for DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH.) These variables can be dangerous because, if they are set and another dynamic library is in one of them that matches the one your program looks for at run time, then incompatible or malicious code can be run if the variables mean another library is found first (the search order is all-important). (As a rule, they should be avoided unless absolutely necessary.) If you'd like references, here is the Apple documentation that I used: 2(a): GNU Make: 10.3 Variables Used By Implicit Rules (http:// developer.apple.com/documentation/DeveloperTools/gnumake/make_10.html) 2(b): GNU C/C++/Objective-C User Guide: 3.19 Environment Variables Affecting GCC (http://developer.apple.com/documentation/ DeveloperTools/gcc-4.0.1/gcc/Environment-Variables.html) 2(c): The dyld(1) man page. (The first two also come in the Reference Library that you can download and install from the Apple Developer Connection.) In light of the above, I agree with Vincent that specifying MacPorts' default search paths only by environment variables that fall into 2 (b) above would be best, we could then be much more confident that: (a) search paths will be overridden only on a port-by-port basis, either via configure.args or via CFLAGS, etc. in configure.env; and (b) the presence of other ports won't muck up compilation like it did for lynx here. Apologies for the length of this post, and do keep in mind that, though the above is long, it's still only my two cents. I hope you're enjoying your weekend. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Mobile: +61 403 855 677 Email: boeyms@fastmail.fm