-I/usr/include

[Daniel Jacobowitz]

On Fri, Mar 30, 2001 at 11:04:38AM +0100, Nathan Sidwell wrote:
> "Joseph S. Myers" wrote:
> > It's already documented in gcc.texi that you shouldn't do that, but the
> > documentation tries to tell you how to do it anyway (and is very out of
> > date, referencing /usr/local/lib/g++-include).  So, at least change the
> > documentation to say "don't do that", without trying to tell people
> > exactly what directories to include manually.  (The include search paths
> > should be documented, but not there; if someone wants to handle the
> > include path manually they should be using -nostdinc -isystem and know
> > what they're doing.)
> 
> What I forsee when 3.0[*] is deployed is people doing what I
> did for random package
> 	configure
> 	make
> 	*bang*
> If I'd got a nice big warning saying
> 	'don't do `-I/usr/include''
> rather than eight million confusing diagnostics, it would've been more
> obvious. [in this particular case, it was unintentional that configure created
> a -I/usr/include]
> 
> Perhaps what is needed is that when inserting a -I directory into the search
> path, we check to see if the directory is already known later on down the
> list, and if so issue a diagnostic such as
> 	warning, changing search order for `dir'
> this is especially true if we're moving a directory into the user search
> path which already exists in the system search path.
> 
> thoughts?

While the subject is up, I have a patch mostly-written to 'poison'
directories at configure time.  That is, if we are configured to use a
prefix of /opt/foo/bar and be a cross-compiler, and the user specifies
-I/usr/include, we pretty much know they're going to regret it, so we
shout.  Is this something that would be useful?

Also, does anyone have a preference on syntax?  I was planning on
--with-poisoned-includes= and --with-poisoned-libs=.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team