> export CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH}:/dir/to/add:/another/one
> 
> which is done to prevent overwriting any formerly set CPLUS_INCLUDE_PATH,
> but has the side effect of adding "." to CPLUS_INCLUDE_PATH if it *isn't*
> set.

	Indeed.  This behaviour is also documented in the gcc man/info pages.

	Now the question is: why do you prepend $CPLUS_INCLUDE_PATH in the
first place ?  I'd expect to _append_ it to your own list of paths, thus
preventing this implicit "." to be added automatically:

export CPLUS_INCLUDE_PATH=/dir/to/add:/another/one:${CPLUS_INCLUDE_PATH}

	Doing so seems more logical (to me).
	For instance: your system contains a library that you want to
replace by a newer version you installed in /dir/to/add (assuming this
directory is in your user space, and is not rooted as written here).
Prepending the /dir/to/add path is the only way to let the compiler
"see" the newer version first.  Otherwise, appending this path to
those given in the former CPLUS_INCLUDE_PATH could simply have no
effect: maybe there is another, older version of this library in the
initial CPLUS_INCLUDE_PATH's.

> Surprisingly, this is the first time it actually
> borked up a compile attempt...

	Among other possibilities:
- The new build system is not mature yet, maybe there's some deep issue
   here that I overlooked;
- Not so many packages automatically configure & build the required
   independent third-party libraries;
- Not sure how many people use the *_INCLUDE_PATH in general (honestly
   I didn't know about it before you reported the problem)  ;-)

	Anyway, version 3.6.1 will have configure handle this situation
automatically (at least my tests seem to work).

	- NC

Post a reply to this message