gcc46 header search path

[Warner Losh]

On Jul 6, 2012, at 1:11 PM, David Chisnall wrote:

> On 6 Jul 2012, at 17:54, Andriy Gapon wrote:
> 
>> Yeah.  Honestly speaking I myself was not aware of what is written in that link
>> and I thought that our gcc ports (from ports) added /usr/local/include to the
>> default search path by some mistake.  And if somebody asked me what I thought
>> about the idea of adding /usr/local/include to the default path, I'd say that it
>> was a stupid idea.
> 
> Why?  The number one question I get from developers new FreeBSD is 'I wanted to use libfoo from ports, I stalled it, and now [gcc,clang] doesn't find the headers, why not?'  No one has yet provided me with a sane reason why our system compiler would not look in the standard locations where we install headers and libraries.

Because they aren't standard locations.  Or at least didn't used to be standard locations.  At this point, I'd say it is likely better to include the new path than not, since it has become standard since FreeBSD started tracking gcc.

>  Running configure scripts on FreeBSD is a colossal pain because of this - you often need to explicitly say -with-foo-include=/usr/local/include -with-foo-lib=/usr/local/lib for an arbitrary number of values of foo, depending on the library.
> 
> Please, please, please, can we put our standard library and header paths in the compiler standard header or library paths, or can someone give me a good reason other than 'it's a stupid idea' why we should force every single program that anyone compiles on FreeBSD to do CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib?

The reasons are that /usr/local/include superceds anything in /usr/include.  This is dangerous.  Users should get just the system default libraries and headers when they compile unless they ask for more.  That's what makes it stupid.

However, regardless of my opinion, I think this may be a case where the avalanche has started, and it is too late for the snow flakes to vote.

Warner