lynx port

[Boey Maun Suang]

> 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 at fastmail.fm