Boey Maun Suang
boeyms at fastmail.fm
Sat Mar 31 01:16:25 PDT 2007
> 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
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
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://
2(b): GNU C/C++/Objective-C User Guide: 3.19 Environment Variables
Affecting GCC (http://developer.apple.com/documentation/
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.
Boey Maun Suang (Boey is my surname)
Mobile: +61 403 855 677
Email: boeyms at fastmail.fm
More information about the macports-dev